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.
Related
In VS 2019 the option to initialize projects on the C# Interactive console is missing when targeting .NET Core.
The option is also missing in VS 2017 and there is a related question for VS 2017. However the answer to this question mainly confirms that issue but is not offering a solution.
Does anyone knows if there is a technical limitation and therefore this feature is simply not feasible for .NET Core? Anyone having a good workaround to still initialize the project (with the complete context) manually?
Does anyone knows if there is a technical limitation and therefore
this feature is simply not feasible for .NET Core?
I'm afraid the answer is negative.
So far this option only supports for .net framework, and not for .net core project and .net standard project temporarily.
To get this option available for .net core projects in VS it needs support from both Project-system and Roslyn. For now the Project'system work is done, you can track this issue to follow the progress of the rest work in Roslyn.
Anyone having a good workaround to still initialize the project (with
the complete context) manually?
Go View=>Other Windows=>C# Interactive to get the window,and use #r command(#r "Path/MyDll.dll") to load the assembly manually.For complete context,you also need to manually load all the referenced assemblies.
Actually not a good workaround, it seems there has a way to go before the product team complete the feature, sorry for the inconvenience :-(
I've read some things about .NET Standard and .NET Core, and generally they seem to say something like "This is the new way to do things, and here are the advantages and disadvantages."
What I haven't seen is a good, clear explanation of what was wrong with the status quo, such as .NET Standard and .NET Core were even necessarily. To really judge what I should use these for, it would be helpful to know why they exist at all.
Can someone give a clear (and not necessarily concise!) explanation of (a) what problem .NET Standard and .NET Core are intended to solve, and (b) how they solve it?
.NET Standard is a set of library contracts. Each version includes all the contracts of the previous version - so everything in netstandard1.4 is in netstandard1.5 for example.
.NET Core is an implementation of .NET Standard (and some extra functionality) which runs on Windows, Linux and OSX.
Biggest problems they solve:
Not having a Microsoft-provided/supported toolchain and runtime on Linux/MacOSX. Saying that you could only run .NET-based server code on Windows or Mono was simply untenable.
The Portable Class Library mess with hundreds of different profiles giving partially-overlapping API surfaces to target.
PCLs in particular were very hard to work with for class library authors such as myself. The mess came about because there were multiple efforts to bring a .NET runtime to different devices without enough coordination to provide a coherent API surface to target.
Now multiple vendors can target particular versions of .NET Standard, and anything targeted to that version or higher should work. For example, my Noda Time library targets netstandard1.3. Suppose a new mobile phone vendor comes out with a completely new implementation of .NET, with a completely new kind of application - but says they support netstandard2.0. That's fine - a user of that new platform will still be able to install the Noda Time NuGet package and (implementation bugs aside, of course) they'll be able to use it. I don't need to know that the platform even exists.
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 am preparing to start on a new short-term contract (1-2 months) that involves replacing an Access application by moving it to ASP.NET and SQL Server.
I am only responsible for the ASP part and connecting it to the database.
The only requirement is that whatever technologies I use be relatively well-known in the area, so that if they need to have someone else work on it, it isn't specialized knowledge.
So, I could do this in Rails or ASP.NET, but, when should the development be aiming for .NET 4 Framework, as there are many changes coming out that may be advantageous to use.
Or, even though it may be useful, when is it better to just ignore new features and stay on an older version of .NET?
I am assuming that hardware isn't the limitation, as many computers won't be able to run .NET 4 Framework, but that would be an issue for a hosting company, as they can find a hosting company to support whichever framework the application is designed for. If Rails makes the most sense, as their hope is to have the application written quickly, but have it reliable, then again, the hosting company would need to support it, or they use a different one.
This company hasn't used a hosting company, they need to find one, so there isn't a relationship that could be an issue.
UPDATE: Part of my concern is that initially the application will not require javascript, but phase 2 will be to make it more interactive, as some clients won't be allowed to have javascript on their computers. In order to limit how much javascript must be known by a developer there are frameworks that will adapt to browsers and situations fairly well, which is why I am also thinking about RoR and the fact that there appears to be changes coming out in .NET 4 that may help with this.
As a general rule of thumb, I wait one year before building sites in a new framework unless the client specifically asks for the newest technology. This has worked out very well for me. The advantages are:
The technology is much more stable (hotfixes, service packs, etc.)
Common complaints about missing functionality are usually resolved
Hosting companies, support communities and corporate IT departments have had time to get used to the technology, find out more about it, play around with it and have it mature within their organization
Unless there is specific need for new functionality introduced by .Net 4, there is no point in subjecting your clients to the immediate problems with an initial release, or making it more difficult for them to find hosting. You should either investigate all of this up-front, or use .Net 3.5 in the meantime.
The only requirement is that whatever
technologies I use that it be
relatively well-known in the area, so
that if they need to have someone else
work on it, it isn't specialized
knowledge.
I would have thought that requirement was enough not to develop this project on .NET 4.0 - it takes time for a new framework version to filter down into the market, and it will be a while yet before there are a lot of developers around with .NET 4.0 experience.
Also, you would be essentially developing on top of a BETA product - while I'm sure most of the features will remain unbroken from BETA -> RTM, there is always a risk that something will break or not work like it did in BETA, so why risk this on a commercial project?
I wouldn't target .NET 4.0 yet on a commercial project unless there was a specific reason for doing so, and even then you would have to have buy-in from the client, ie "I can do this much more quickly and with less effort if we use the current beta version X rather than established, stable version Y" - good luck with that.
I worked on a commercial project that used the CTP version of LINQ to SQL - then when we went to VS2008 / 3.5, suddenly everything changed and we had to make a lot of changes just to get LINQ to SQL working again.
Stick with 3.5 - it's easier for hosting and getting developers.
Just a couple of thoughts, I wouldn't even think about creating an application for production use in .NET 4/ASP.NET 4 until:
There is a release candidate. It's
not the first time I've seen
features in beta's not make it to
RC/RTM.
Microsoft have permitted development and deployment
of production applications by way of a 'Go
Live' license.
There are some hosters out in the market such as OrcsWeb who are participating in public beta testing, but they aren't intended for production use.
I'd run with the .NET 3.5/ASP.NET 2.0 or MVC bits for now. Better safe than sorry.
Generally speaking it's going to be easier finding hosting for a Rails app. If you want to run .net 4.0 you're probably going to have to run a VPS or dedicated machine. However if you're bailing after the application is finished and assuming your client is in Knoxville, they're going to have a tougher time finding a Rails developer to maintain the application.
I think the bigger question is your role. They're looking to you to solve this problem for them. Are you productive in both technologies? How about getting a Windows server up and running? A Linux server? How's your SQL Server vs MySql? I'd guess that you're probably stronger on one stack vs the other - for a contract that short I wouldn't want to be doing a lot of experimental development.
i wait until the OS that everyone will be using has it.
Just last month i took a dependancy on GDI+, which first shipped with Windows XP.