I understand that the "1.0" in "ASP.NET MVC 1.0 Futures" means that it is the ASP.NET MVC Futures built against the ASP.NET MVC 1.0 RTW (final/release to web). What I'd like to know is whether the Futures code is solid enough to treat as 1.0 / gold quality?
We're about to jump into ASP.NET MVC for the first time and it came up that we should consider adding Futures to our build. Problem is, if it's alpha code I'm wondering if it would be wise; stability is going to be very important for us.
It is the official release, not the beta. However, like any Microsoft product, 2.0 will always better if you can wait, but as far as your question concerned, it's the full release.
Stability is good anough. The only problem is that Features might be cahnged in the future. Anyway, I use them in productino websites without any problems.
Related
So begins from 0.75.1, Rebus no longer supports ASP.NET 4?
My question will be:
Is 0.75 a stable release for .NET 4 project?
Are we going to continue get bug fixes (if any) for .NET 4 target project?
Thanks
As of 0.75 Rebus has targeted .NET 4.5, which was a requirement to support the usage of async/await in the library.
I'm not an expert on ASP.NET and whether the version follow the versions of .NET, but Rebus will work as long as your host process targets (at least) version 4.5 of the framework. If ASP.NET 4 is only available for projects that target .NET 4, then that implies that you cannot use versions > 0.72 of Rebus.
And then an answer to your questions:
You should pick the latest version of Rebus, but that requires that you target (at least) .NET 4.5. If that is not an option, you should pick Rebus 0.72 (which is the last version available that targets .NET 4).
No (*)
As for the (*) above, I'd like to make the following fairly long and elaborate point: Generally, you can't count on getting bug fixes for the free, open-source software you have downloaded and are using, freely, without having paid a cent - at all!
If you want to be able to reliably count on getting bug fixes for your free software, I suggest you get a support contract with a company that is willing to provide that service. My employer provides that service for Rebus in case you're interested.
With that said, I'll add that I am a pretty helpful person, and I do a lot for people to have a nice experience with Rebus, but I am sure that you can understand that I cannot promise to provide bug fixes for the old versions.
I will be around for helpful advice if you run into something, but - as I am developing Rebus mostly in my spare time - you can probably understand why I need to concentrate my efforts on the current version.
Can anyone tell me main steps to consider while migrating 1.1 to 3.5 windows based application?
What are the steps need to consider at initially while planing for migration?
as per i know this applicatin i need to migrate like wsf and wpf and soo on.
You'll need to upgrade the projects to .NET 3.5 Framework and then build the solution. Fix any compilation errors (there will likely be a few), and then you will need a large QA effort to make sure you didn't break anything. It's really more of just a time sink than anything you need a specific plan for.
If you can manage it, see if you can write unit tests for your app, and then after the upgrade, make sure all those unit tests pass.
http://www.codeproject.com/KB/books/net2_cs2_newfeatures.aspx
http://www.simple-talk.com/dotnet/.net-framework/.net-3.5-language-enhancements/
I guess you should look through new features and check whether a change in code is necessary for that new feature.
With the amount of effort involved and the changing to newer technologies like WPF, I think you are better off doing a re-write of the application in 3.5. We have had some ugly upgrades done at my place of work that may compile and run as 3.5 but are really just hacked 1.1 applications.
Okay today, as most of you noticed Framework 4.0 has been released. I've been working on a project which is being built on framework 3.5. Since I want to use dynamic keyword and most of the asp.net features like Tableless Menu Control, ClientIDMode and clean web.config etc. I am kinda urging to migrate the unfinished project to 4.0 but I am little hesitating about that.Some times I think it is way better to wait for SP1.
So what do you think about it? You guys will migrate to unfinished projects or will still hang out with 3.5 for a while.
Thanks.
The .Net 4.0 runtime environment has been out for a while (mind you not RTM, but RC1 and so forth). A lot of people have tested it and I would guess that almost all of the bugs have been shaken out. There should be no problem switching at this point. They have introduced a number of items that improve .Net. Are they necessary, no, but they can make programming in .Net easier.
You can always download 4.0 locally and test it out on your project. Worse comes to worse, the project blows up and you reload it from your source control system.
What you should be aware of is that there are breaking changes in both C# and VB.Net in 4.0 runtime environment. You'll need to watch out for those.
The following probably applies to most framework-base development.
Do the new features save more time than fixing the old things the upgrade breaks?
If you're going to waste lots of time making old things work, perhaps you're better off just to sit it out on 3.x and port to 4.x at a later phase.
If you really need features from 4.0 and would have to spend time implementing them yourself, perhaps it's a net time saving.
Can you support this version of the framework? (ie can your server people handle the upgrades and monitor things okay?)
If your server bods can't make this work in the field, give up now. I don't know your organisational structure or who runs your servers but I know some companies have a pretty thorough testing regime they'll put software through before allowing it. As a brand new version, they might be weary.
And let's be frank, just because something goes through several pre-release versions, they don't catch every bug because they're rarely used in production scenarios. You know the drill.
And if installing 4.0 on the server breaks old things, you might be waiting a long time.
Is your project's launch likely going to be after the first round of bug fixes?
If you're developing this for 3+ months away, you've probably got enough time to sort the platform issues, fix the code issues and get framework bugs reported with the (blind) hope that they fix them or you can work around them safely.
If you're launching tomorrow, it's not enough time to test it.
I will only upgrade when there is a need to do it. For example I have one application that must use features delivered in .Net Framework 4. So that application will get upgraded ASAP.
I have another application that is 3.5 with no driving need to upgrade at this time. That one will get upgraded when time and budget allows.
This question is similar to my earlier question.
I have used ASP .Net in Visual Studio 2005 about 4 years ago. How long would it take to get back up to speed with the latest versions?
That depends on how much you "used" it. An experienced developer should have no trouble updating his knowledge of the 3.0 to 3.5 Framework changes and language specific changes. The largest introduction, I'd say since then has been LINQ, giving the ability to query data from the language level rather than SQL.
But if you're not an experience developer and don't have a good foundation in the previous version, most of what you'll be learning will be the Framework 3.0 and VS2005.
So, ultimately, if you're just going from VS2005 to 2008, it shouldn't be much trouble at all.
Not very long. The major addition to VS 2008 is support for Linq, but you don't have to use this (or any of the new features).
The IDE is extremely similar to VS 2005.
Essentially, 2005 targets the 3.0 framework, and 2008 target the 3.5 framework, but these are both just expansions of the 2.0 framework, and not new versions (unlike the change from 1.1 to 2.0).
If you were already proficient in it earlier, then you'll be able to jump into it very quickly again. The core concepts haven't changed much, so you should feel right at home.
If you were able to produce and application back then, you can probably still build exactly the same application now.
As has already been stated, .NET v3.5 is merely v2.0 with extra bells and whistles, like LINQ and AJAX. These are tools in a broader toolkit, and there is no requirement that you must use any/all of them.
So start where you left off. Refresh yourself, and once you are back in the swing of things, have a look through some of the latest enhancements, and pick out one or two that you think will be useful to you. One step at a time!
Everyone else is correct that it should be easy. I'd just add that the ListView control is one of the additions, so be sure to check that one out.
It depends on what you want to use ASP.NET for.
If you live in the HTTP Request/Response world, it will take time. Most of that time will be spent trying to shift documentations which completely ignore the Requrest/Respone world in favor of ViewState and other similar items.
If you want to go ViewState way, not too long, since Microsoft's website is overflowing with tutorials on it.
Take a look at some of the starter kits like Kigg, DinnerNow, and DropThings . You'll get an idea of MVC, WCF and LINQ. Ignore that sinking feeling and get to work learning!
Has anyone built a website with IronPython and ASP.NET. What were your experiences and is the combination ready for prime-time?
The current version of ASP.NET integration for IronPython is not very up-to-date and is more of a "proof-of-concept." I don't think I'd build a production website based on it.
Edit:: I have a very high level of expectation for how things like this should work, and might setting the bar a little high. Maybe you should take what's in "ASP.NET Futures", write a test application for it and see how it works for you. If you're successful, I'd like to hear about it. Otherwise, I think there should be a newer CTP of this in the next six months.
(I'm a developer on IronPython and IronRuby.)
Edit 2: Since I originally posted this, a newer version has been released.
Check out the Dynamic Languages in ASP.NET page on Codeplex. This has the newest IronPython bits. It doesn't give you any Visual Studio integration, other than the sample website project, but that's coming.
Keep a look out for ASP.NET MVC
The IronRuby guys have got some internal builds of MVC to work with IronRuby, and IronPython 2 and IronRuby have a lot of code in common with the DLR.
I'm not sure if they'll support IronPython/IronRuby when MVC is released, but it's definitely worth keeping your eye on anyway - The old ASP.NET forms-based development model is old, busted, and the sooner it goes away the better.