is moq 4.0 stable enough or should I just use 3.1?
I bet it's been well tested.
Unless you need a particular feature of 4.0, stick with 3.1 until 4.0 leaves beta. You'll probably be fine if you jump aboard 4.0, but it you value your project and sanity, and have no compelling reason to move forward, then the stable line is the appropriate path.
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.
Would be glad to see some feedback from you in using async ctp in developing or even production.
We are starting big project and pay much attention to async programming model, so we are going to make our code 4.5 features ready buy using async ctp.
So have somebody faceoff some problems with it?
P.S. we can't use 4.5 beta in case of azure and visual studio aspects/
I would advise you against using the CTP in production, because it contains at least one serious bug. It never was meant to be used in production, it's just a technology preview.
The beta does not contain this specific bug, but I still would be very careful when using it.
Also, depending on what features of the CTP you are going to use, you might need to make changes to your code to make it work under .Net 4.5 beta (or, presumably, the final release), because there were some changes between the CTP and the beta.
Well, I looked deeply in decompiled methods with async/await syntax (the oonly feature we need from async ctp) and it just compiler magic (maybe very few runtime changes) that creates new class where all await statements starts in different threads. So I think it's quite safe to use it until 4.5 release.
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.
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.