Now that Visual Studio 2010 RC is released I was wondering if anyone knows what pros/cons there are to upgrading my existing ASP.NET applications to target the .NET 4 framework? (Apart from waiting until the Final release which should be even more stable)
If you are not going to rewrite some parts of the application to use new features in ASP.NET 4.0, I don't think there are many benefits. Unless they introduced performance optimizations for already existing functionality, but I don't think you would get those automatically without modifying code.
Otherwise there are plenty of goodies like URL Routing, SEO optimizations, ViewState performance, etc.
At least, you must check if your webserver have support for ASP.NET 4.0 application pools.
Pros: You will be ready when it is final
Cons: Be ready for quite a few issues, if you have the time.
Here is a list and overview of some of the issues people are encountering and some praises:
http://weblogs.asp.net/scottgu/archive/2010/02/08/vs-2010-net-4-release-candidate.aspx
And my favorite resource as it is impossible to give you a break down of Pros and Cons considering what may be a pro for me, may be a con for you and vice versa:
http://social.msdn.microsoft.com/Forums/en-US/category/VSPreRelease,netdevelopmentprerelease,visualstudioprerelease,vstsprerelease
http://blogs.msdn.com/architectsrule/archive/2010/02/19/10-4-episode-41-downloading-and-installing-the-visual-studio-2010-release-candidate.aspx
If you're going to be using C# for your development, then here is one big thing that the next version of the framework and C# will have; Dynamic Types:
From Scott Hanselman's blog:
C# 4 (not 4.0, the marketing folks say it's .NET 4, etc.) adds the dynamic keyword. I've explained this saying:
"There's no way for you or I to know the type of this now, compiler, so let's hope that the runtime figures it out."
The key point here, in bold, because it's significant is: having the type dynamic means “use my runtime type for binding”.
This is something quite different from the current version of C# and could have some pretty signifigant ways in which code is written. So hidden in all of the hoopla, the new framework does have some added value compared to the current frameworks.
Hope this helps some.
You have the go live license --> you can use all new asp features in production.
But you will have a few problems with VS.
Related
We are in the process of migrating from .NET Framework 4.8 (VS2019) to .NET 6 (VS2022) and ran into a quite large problem regarding User Settings. That is, the Settings Designer used when opening the Settings.settings file.
According to
https://developercommunity.visualstudio.com/t/VS2022-Properties-gt;Settingssettings/1690711
the possibility to use custom types (e.g. enums from another project/package) has been completely removed in “.NET Core projects” and that includes .NET 6 I guess. The “Browse” menu alternative for selecting types has completely gone away.
This is a quite large reduction in functionality! And it makes it really hard for us to migrate to .NET 6. We have a lot of user settings (mostly Enums) from multiple external assemblies and packages. For these kind of UserSettings, the SettingsDesigner in VS2019 was so easy to use.
So it makes me wonder: Will the UserSettings functionality soon be totally deprecated?
Any ideas of an alternative simple framework to use?
The only functionality I’m looking for is the possibility to handle that UserSettings are added and removed between deployed application versions. For an end-user that gets a new application in a new version that includes some new UserSettings, default values should be used.
Any help would be very much appreciated!
PS. If anyone with some influence over the SettingsDesigner in VS2022 reads this: You would make this system developer very happy if you once again made the UserSettings feature useful 😊 DS.
I have been working for 4 years as a PHP developer and I'm currently transferring to ASP.NET (Since I have 4 years of C# experience too, and selected PHP because of specific conditions - now I wish to use my C# knowledge and the .NET Framework is impressive).
When developing with PHP, I always use a framework - or something I've wrote myself (I'm working as a software architect...) or Zend Framework / Yii etc - the reasons is lack of classes, tools and OOP in PHP (such as MVC, ACL, Cache etc.)
When working with ASP.NET MVC 3, I see that combining the MVC framework and the general .NET framework I have many tools, and here is my point: when developing in ASP.NET, do you need to use any other framework than .NET? (just like in PHP I'm using Zend).
If so, there's any recommended frameworks?
Thanks! :)
In a .Net world, there are many options infront of you. see below popular vendors;
www.devexpress.com
www.telerik.com
www.comonentone.com
www.infragistics.com
But most of the time, asp.net is perfect itself. And when you are talking about mvc3. You can use another view engine instead of using Razor(the default one) such as spark. So, i mean that asp.net itself can be expended accroding to your needs.
And when you are working with mvc3, then you have best choice which entity framework. There is alot of support out there for this framework. So good luck in this.
Yes, there are other frameworks that you can choose to use alongside .NET MVC - but I myself haven't chosen to utilize them in any recent projects. Here are a few examples aside from what others have already pointed out:
http://www.springframework.net/
http://sparkviewengine.com/
That said, while I don't personally use frameworks like I mentioned above here in no particular order are a few tools that I have found that I have come to rely on while developing applications within ASP.net MVC:
Fluent Nhibernate - If you choose to use Nhibernate as your ORM
Ninject - Dependency Injector
AutoMapper - object - object mapper
ELMAH - error logging facility
lg4net - logging etc
Check out Telerik http://www.telerik.com/ They have some great tools like their RadGrids and specific imput textboxes that once you get used to will save a ton of time and add a lot more flexibility. Definitely worth a look.
No THE framework has everything you normally need. But the amount of tooling available is tremendous! We use asp.net 4.0 but we choose DevExpress controlls to get nice look and feel and functionality that would cost too much to build myself.
We worked with almost every component builder in the last 10 years but DevExpress is our favorite for one simple reason. Super fast support! And I agree with the above comment about Infragistics very disapointing support!
But again those vendors or other community frameworks are there too make our life even simpler. By itself THE framework can solve almost everything from THE core libraries.
Good luck switching to C# again my favorite language too!
I am ASP.NET developer from last 5 years and still loving it. There are lots of good voices in air about Ruby on Rails. I want to ask to community, Is there any worth trying to learn Ruby On Rails as a ASP.NET web developer on following point of view.
Scalability
Documentation
Community Support
Hosting Solutions
Deployment
ETC.
I'd take a gander as ASP.NET MVC. This way you can stick with the .NET Framework yet still get some of the things you probably want out of RoR.
ASP.NET MVC is very lightweight and easy to scale with some of the APIs it provides (SQL storage for sessions or even Microsoft Velocity).
ASP.NET MVC has lots of support from the community and thus has lots of documentation and feedback from the community and Microsoft itself.
Lots. Check out http://www.codeplex.com/ASPNET for more information.
Well, ASP.NET MVC is bin-deployable. So as long as your host supports ASP.NET 3.5 there's nothing else you need. They don't need to have ASP.NET MVC installed in any sort of way. So if you wanted to, you could easily use a shared host.
Deployment is very easy with ASP.NET MVC and with the changes coming to Visual Studio 2010 for easier deployment of web sites via "Packages." I currently maintain 2 ASP.NET MVC sites and find it with bin-deployment to be just the same as a regular ASP.NET WebForms site.
I'm now in your shoes, because I'm learning RoR after commercially developing in .NET for 5 years.
Here is my two cents:
Scalability: I believe that rails can scale quite well, there are numerous options available, such as mongrel clusters on linux.
This one is a bit worse than on .NET. But the community is very good and you'll never find yourself searching for a good way to go.
See above (it is excellent)
Hosting is not a problem: numerous hosting options available.
I find transition from development to test and then to production better thought of in Ror than in ASP.NET.
I fully agree with Chad's post.
I was half way through development of an app in rails and now i've done a complete 360 and have reconsidered after delving deep into ASP.NET MVC for my day job commitments.
I am now changing courses and looking into ASP.NET MVC for all my personal projects, I think both are honestly remarkably comparable now as I think MS has had a good hard look at Ruby on Rails' feature set and ensured they could match features very closely. After all, if you couple a project with LINQ 2 SQL / EF, ASP.NET MVC and potentially Dynamic Data (if you need that sort of thing), I really can't think of any compelling reasons to choose Rails over .NET, however I CAN choose reasons to select .NET over rails - after all hands down the rich debugging experience with VS.NET, rich intellisense and watcher/quickwatch support plus the ASP.NET MVC framework supports Html Action Helpers, Model Binders, support and encouragement for unit testing, and now with the inclusion of JQuery and JSON results, you're virtually unstoppable.
I suppose besides obviously hosting/licensing costs, Ruby language preference and other personal preferences such as it being open source etc, It's really your choice.
1) Scalability
Rails is just as scalable as any other web-application stack. The only difference is that your single server might get overloaded, and require splitting to 2 servers sooner than it would in .NET due to the slower performance of the ruby runtime. In practice this is not a problem.
2) Documentation
Microsoft do provide better documentation for the core libraries than Ruby or Rails, but the ruby/rails ones are still on the whole very good. I'd consider ruby/rails to be the winner here for the simple fact that you can always view the source for everything. No amount of documentation is a substitute for being able to actually see what's happening.
3) Community Support
I've been nothing but impressed by the community support around rails. I don't know what else to say there.
4) Hosting Solutions
Since phusion passenger got released, It seems to be easier these days to find rails hosting than it is to find ASP.net hosting. This is only going to sway more towards rails as time goes by for the simple fact that hosting companies do not have to pay royalties towards microsoft to deploy rails on linux servers.
5) Deployment ETC.
Capistrano (the most common deployment solution for rails) beats everything else hands down.
Well I dont know anything about the Scalability part, but personaly i started learning Ruby On Rails from ASP.NET a while ago. I really had a hard time finding some good documentation - the class documentation on Rails site was really poor in my eyes, and I had a simple question about what arguments you could put into an actionlink. But maybe it was just me who never found the right place. But personally i think that the ASP.NET documentation is better than rails - at least buy a book, i think thats a good way to go.
Number 3. Im pritty sure that there is very good Community Support for rails you just have to find the right forum or other media that suites your liking - maybe this what was I did wrong.
Number 4. There is alot of hosting solutions for Rails, but not as much as ASP.NET or PHP. I think you have to research this your self, and find out, if there is anything that suites your likeing.
Number 5. Ruby should be very easy to deploy, it has a notion of a development, test and production database. It uses migrations, so updates in the database schema is seamless - thats very cool. It is scripting, so it should be a matter of xcopy from the development computer to the production server.
The reason you should choose Ruby on Rails is if you like the MVC pattern. The MVC pattern is genius, and ruby is a great language when you learn it. Maybe take a dive into the ASP.NET MVC, and see what its like - then maybe move to Rails. Then you only have to learn a new language, and not a new arhitecture, framework and language at the same time.
Remmember this is from a ASP.NET Developer who sniffed to Rails, but gave up, doe to the lack of ability to find really good documentation, and there was always some strange errors, from the editor or Rails - but thats properbly a newbie thing :)
But if you have time, by all means learn it. Some developers say that we should learn one new language per year, and Ruby is a great candidate for that.
I am a .Net developer that has been tasked with upgrading a classic asp website to asp.net. The website is currently running on luck and bubble gum but there is not enough time or money to stop progress and do a full rewrite. Of course I will still need to be able to deliver new features while I am upgrading.
What strategies should I use to make a smooth gradual change to asp.net? Should I convert to a single tier .net solution and then refactor to a proper multi-tier solution or should I design my business and data layers now? Should I go straight to 3.5 or is it easier to just get to 1.1 and upgrade to 2.0 or 3.5 after?
A full conversion would probably take 3-5 months. There is also some existing 1.1 code, which is why I am considering using that as a jumping off point.
Don't throw away your code!
It's the single worst mistake you can make (on a large codebase). See Things You Should Never Do, Part 1.
You've invested a lot of effort into that old code and worked out many bugs. Throwing it away is a classic developer mistake (and one I've done many times). It makes you feel "better", like a spring cleaning. But you don't need to buy a new apartment and all new furniture to outfit your house. You can work on one room at a time... and maybe some things just need a new paintjob. Hence, this is where refactoring comes in.
For new functionality in your app, write it in C# and call it from your classic ASP. You'll be forced to be modular when you rewrite this new code. When you have time, refactor parts of your old code into C# as well, and work out the bugs as you go. Eventually, you'll have replaced your app with all new code.
You could also write your own compiler. We wrote one for our classic ASP app a long time ago to allow us to output PHP. It's called Wasabi and I think it's the reason Jeff Atwood thought Joel Spolsky went off his rocker. Actually, maybe we should just ship it, and then you could use that.
It allowed us to switch our entire codebase to .NET for the next release while only rewriting a very small portion of our source. It also caused a bunch of people to call us crazy, but writing a compiler is not that complicated, and it gave us a lot of flexibility.
Also, if this is an internal only app, just leave it. Don't rewrite it - you are the only customer and if the requirement is you need to run it as classic asp, you can meet that requirement.
Having been a longtime classic asp programmer, and now an ASP.NET dev, I would take the time and architect it properly in the 2.0 framework (3.5 if you want/need the features).
My last job we had a large handful of very badly build classic asp apps that we were rebuilding, and the "nuke and pave" approach was the most successful. Use the existing classic app as your functional spec and wireframes, and build your tasks and tech specs off of that.
How long would a complete conversion/rewrite take? It's also going to depend on how you've structured your original project.
I can answer that you should just target v2.0 (3.5 if you want/need it's features) from the beginning. There's no need to subject yourself to 1.1 of the framework.
Try these links
Migrating from ASP
Key Considerations
Converting ASP to ASP.NET
ASP to ASP.NET Migration Guide
You may want to look at the new ASP.NET MVC framework. The level of flexibility is amazing and the coding style is slightly more akin to the ASP classic approach, albeit with much better separation of church and state.
Take a look at Snitz Forums (www.snitz.com) - they are currently in ASP but the port to ASP.NET is almost complete. Both code bases are available for you to look at so you may get an idea of how it has been done there to help you.
I would avoid going into .NET 1.1 since Microsoft is ending support for v 1.1 of the .NET Framework on 10/14/2008. The extended support runs through 10/8/2013 but is typically expensive to purchase. Any bugs or security holes will not be addressed and are your problem.
http://support.microsoft.com/lifecycle/?LN=en-us&x=11&y=10&p1=1249
Paul
easiest way to do it is to just jump in head first. get some asp.net books and dive into visual studio. Do the examples, play with it, build something fun for yourself. You'll learn by doing.
I'm also working on a gradual migration from classic ASP to ASP.NET. Our first phase is migrating some common logic from an ASP include to a .NET assembly that is exposed to COM Interop so they can be called by both classic ASP and ASP.NET. I've written some tests using ASPUnit to verify the behavior after migration to the .NET assembly (with the added benefit of safer refactoring). Once the core logic is in .NET, we can begin creating new pages in ASP.NET and migrating individual ASP pages to ASP.NET at our own pace.
I would recommend .NET 2.0 or 3.5 over 1.1. ASP.NET MVC looks like an attractive upgrade path.
I am recently in charge of an older app written in C# using asp.net 1.1.
Are there any resources to guide me in converting the application to a newer version of of the .NET Framework.
My main pause is that there are ton's of customized DataGrids in the app as it is written now and since so much of the code needs to be rewritten to use GridViews ...
is it worth trying to convert the grids in the application to use Silverlight in the attempt to move this code into the future.
I had a similar experience, and the only thing that we had to replace was a third-party control that we were using in the 1.1 app, and the vendor had gone out of business an never released a version that worked with .NET 2.0. We ended up replacing it fairly easily with an AJAX Control Toolkit control.
Other than that, the compiler does a pretty good job of telling you what to do with respect to deprecated method calls.
I'd suggest making a copy of the code and upgrading the site in Visual Studio and see what happens. Just open the solution in Visual Studio 2005 or 2008, the IDE will walk you through the upgrade automatically. Get it to compile, then if you have any documented tests you should run through them. If not, you'll want to plan testing to make sure all your functionality still works like it did before the upgrade.
Migrating to Silverlight sounds like fun, but if you can get it upgraded and working, I'd probably push that off until a later release -- my experience tells me that you might get into trouble if you bite off too much at once if there is no show-stopping technical reason.
This MSDN document may be useful to you as you upgrade your application, it contains lists of breaking changes between 1.1 and 2.0, and work arounds for resolving them:
Breaking Changes in .NET Framework 2.0
I would suggest that as part of the upgrade you opt to move to a Web Application Project rather than a Web Site Project, as the former is conceptually similar to the VS2003 web project model.
Here's a nice short post summarising the differences:
http://maordavid.blogspot.com/2007/06/aspnet-20-web-site-vs-web-application.html
As others have said, don't worry too much about the DataGrids, the upgraded site should be backwards-compatible in this respect.
Regarding DataGrids - I don't think you have too much to worry about, DataGrids still work in current versions. It's just that going forward, you should use GridViews.
I am sure there are other things you may want to check into though, deeper framework issues. But I don't know enough about those things to speak to that particular point.