I have a working ASP.NET MVC 5 application and I need to run it under vNext. I assume there is no simple import possibility, so I'll need to do it manually. So basically I have a blank vNext project and a ready MVC5 project. I'll try to copy files and rewrite all dependencies in JSON config files. Maybe anyone tried to do something similar and can recommend best way and key points to achieve this task?
There are a few gotchas. One of them is the usage of notorious HttpContext.Current. It's basically gone in vNext. See if you have any usage for this inside your codebase.
As a general approach, in my personal opinion, do not ever try to upgrade an application in one go. There are so many new pieces that it's really hard to get a grasp of in a big giant app. Write small PoC samples to see each functionality in isolation. It will be easier to put them together when you know how each of them behave. I believe that's the best way to both learn the new system and understand the upgrade pains.
I have been following this approach to make it easy to move to the new system. It's a slower approach but it makes me learn the new system in a better way.
Also check out this discussion in ASP.NET Forums.
Related
Updated.
Updated the question since it looks little ambiguous and not the answer i was looking for.
We have a huge .NET application running on MVC and angular. It has multiple projects under the main solution. .
We also have a replica of that application in Node.js for front end developers.
It looks something like this :
What happens is - Front end developers make changes in Node js solution (like js or .less files or controller) - make changes and move those changes to .Net solution which is the actual live project.
Off late - we have issues with developers working with two different solutions (Node and .NET) and keeping two copies of assets everywhere.
We ultimately decided to combine them and bring the whole Node.js application into ours .NET Solution as 6th project.
Something like this
Wondering if anyone has previously done so - adding a .NET application with existing Node.js application. If so any pros and cons to consider.
Some points to note - the Nodejs project and .Net project are completely independant of each other. The idea is to consolidate the applications so that We can either run the .net application or UI application from single solution.
Eventually, we will consolidate all the assets to just one project so that - we dont have to do duplicates.
Also, would appreciate any links where I can see how to start merging these two applications.
You definitely want to look at JavaScript Servcies. Building Single Page Applications on ASP.NET Core with JavaScriptServices.
Made for .NET Core, but you can run .NET Core on Full .NET Framework, which should make it easier to migrate to.
What I think you have is, say, a production version in .NET and a development environment in node.js for developers which prefer that.
At the company I work for, we use AngularJS for our front end and .NET/Entity Framework back end and it works pretty well.
I'm not sure if you are integrating some sort of JavaScript back end in with it or not. Assuming you are going to stick with a .NET backend and a JavaScript heavy frontend, it should be fairly easy.
That being said, nothing in this career is truly "easy". I would recommend using an AngularJS frontend as it has seemingly endless functionality.
Some minor suggestions if you choose that route is to check out John Papa's style guide. great reference for writing AngularJS. Make sure you have consistent naming, especially in Visual Studio as AngularJS can be a little moody.
I prefer to bind values to the view when working on AngularJS, e.g.
vm.title = "Data I want to bind"; in the view: <h1>{{vm.title}}</h1>
If that renders as {{vm.title}} instead of Data I want to bind you know something isn't working. I prefer catching it sooner rather than later.
Dependency Injection is another thing to be careful with, the style guide covers it as well. Basically if you minify your AngularJS files and the minifier removes the information required for DI, your project will break. I've been down that rabbit hole a few times.
If you aren't intending on using AngularJS then forget I said anything. I was just exercising my fingers. I hope that helps shed a little light on your decision.
Looking for suggestions regarding an upcoming project that I am involved in which revolves around adding certain functionality to an existing ASP.NET application running on IIS 6.0 programmed in VB.NET.
To aid in future development the client wants the additional functionality to be as future proof as possible. Ideally I have said that I would like to push for a solution using ASP.NET MVC3, running off IIs 7.5 and .NET 4, written in C#. This solution would act as a seamless addition to the current web-portal appearing probably just as an extra tabbed page.
But they will be completely separate web-apps. Which is crucial.
The main problems I can foresee are firstly sharing session particulars between the asp.net web app and the new application. Particularly with regard to maintaining session state (and not having IIS timing out on one of the apps). Also, conjoining the two "apps" appears problematic in my head, although this may be far simpler than I fear.
I'm asking for suggestions for these two problems if anyone has any ideas please say!
So far I've come up with the following solutions be they terrible or not:
1) Embed the new functionality into the existing codebase (not a great option). This would mean losing any potential future upgrade-ability and also means not following better OO conventions by utilising the MVC framework.
2) Using an iFrame to link to the razor pages of a seperate MVC3 app (the one I'm favouring currently). Allows uses of all new technologies, however downside is sharing session data. Either through iFrame "attributes" (is this possible?) through persisting a session state to a db? (slow?) or even some kind of web service interaction between the applications to push/pull user/session data?
Any advice/suggestions greatly appreciated!
I agree with you that C# and MVC is the "way to go", but unfortunately mixing two applications together is going to give you a whole bunch of headaches, not least the different session IDs. You'd probably have to have a shared database table to map them together and, as you can probably imagine already this reeks of "Band-aid".
What are the ramifications in rebuilding what is existing, in to C#? Perhaps you could suggest a complete upgrade. The client themselves seem to extol the virtues of future-proofing and therefore this would be the way to go. And no, I wouldn't promote the use of a "code-converter", but it really shouldn't be that difficult.
The next thing to consider, I guess, is "future-proof". Is the client worried that VB.NET is going to disappear any-time soon or that it cannot handle anything in the future? I find that a very unlikely scenario, honestly.
I think I've waffled on a bit, but essentially combining two applications, one with old and one with new functionality will cause a headaches. This could be solved by migrating the old site to C#/MVC, and then adding the extra functionality. True, this may seem like a large commitment today - but further on down the road, it will pay dividends.
If the current site can be upgrade to .NET 4.0 there's no reason why you wouldn't extend the existing application.
There's nothing to stop you mixing MVC and web forms (indeed there are several articles on how to do just this). There's nothing to stop you mixing VB.NET and C# (or, so far as I'm aware, to stop you doing MVC in VB.NET).
You'd have to work very hard to convince me of the merits of using iFrames. Very hard. You might be able to persuade me of the merits of running two applications side by side - with the functionality split by folder - but to be honest I'd be much happier upgrading the existing site and then building from there.
I'm going to have to write a big system in January with ASP.NET MVC3 / C#, and need to know how to write a system that will WORK. I do have a bit of experience with ASP.NET MVC and C# but would not call myself an expert. It needs to be extensible so that I can extend it later with new features. How would one go about this? Is there books that explains this topic in detail or should I use trial and error?
In short I need to know good design practice in my code thats extend-able for the future.
Regards
RaVen
The System will be a community portal with forums ratings etc. Cant say more than that << Company Policy>>, The forums I can manage because of plenty open source options... But the rest is up to me.
SOLID == Great Success
Follow SOLID principles in any project and you'll do well.
With regards to core infrastructure/architechure, SharpArchitecture is a good place to start. It is by no means the perfect solution...BUT they give you a good framework to play with and you can have a working system quickly while learning the concepts that work and don't work over time. Take a look and see what you think. It uses NHibernate, Castle and MVC.
Test Driven development will ensure quality for your project. Be strict with yourself, red green refractor. One of MVCs strengths is that it's easier to test.
Professional ASP.NET MVC 2 is a good starting point, though, I would assume that they'll come out with an MVC 3 edition as well. The NerdDinner tutorial contains a lot of ideas on how to structure your application.
Basic advice: work with the MVC architecture, not against it. Understand your application, especially your data model, and layer that onto your application structure. Typically you'll have a controller per model, but not always.
If you want more detailed advice, you'll need to be more specific about your project. I'd suggest coming up with specific questions about various details of your design as you have them, rather than a single question covering the whole project. The latter probably won't get the kind of response you desire.
you can use my "awesome" demo as a start
http://awesome.codeplex.com
If it's going to have to be extensible, make sure you write tests. You'll save yourself sleepless nights in the long run when you fix something, but ended up breaking the entire system.
As far as how to make things "WORK" - that depends on your ability. Read, and look to improve things, but don't get caught in premature optimization or it will leave you dead in the water.
Based upon your edit and your abilities, it might be wiser to select an open source CMS written in ASP.NET MVC and support it. Your skills are good enough, it sounds like, to learn how to write modules and be part of a larger community. You do not sound like you really want to write the whole thing because you are timid about your skills, deadlines, etc. Whilst learning the ins and outs of a well written piece of software, one day you may choose to write your own or contribute to a core piece of the software. There are several to choose from see my comment above under your question.
edit: I also think this will allow you to just start and not worry about every design paradigm people will throw at you for success.
WhoCanHelpMe is a nice reference application. It's built upon S#arp Architecture which is a good starting point for an MVC-application using domain driven design. That will also help you on the way with wiring IoC and db-stuff.
Remember that not every example and framework will fit your requirements, so do as jFar said, think SOLID and make your own decisions based on principals.
You should also look into MEF for extensibility.
We have a ten-year-old ASP application that we are considering planning an update for. We want to take advantage of the new technologies that ASP.NET has to offer, as well as the opportunity to fix some issues with the existing framework (the existing code-base is highly fragmented, nearly impossible to test, let alone debug, and the entire application appears to have been constructed according to the "Farmhouse Pattern".)
To that end, it seems that the time has come to rebuild this application. But, we are a small business, and we simply don't have the resources to either hire out the rebuild, nor to dedicate our small team of developers solely to the task of rebuilding (we've got other tasks on our plate, and can't concentrate on this one particular task for the length of time it would take to fully reconstruct the application).
What, then, are some useful strategies we can employ to help us convert this app, without having it consume all of our limited resources for the duration of the re-write?
Sounds like an interesting challenge. It's definitely not going to be easy, especially if you can't dedicate any resources to the project full time.
If you have a 10 year old application that is working, I would suggest not going for a complete re-write at all. I would start by sitting down and figuring out what you want your end product to be.
Is it going to be an ASP.NET MVC Web Application, an ASP.NET WebForms App, or something else? Once that decision is made, come up with a loose design for an architecture. If you do things correctly, you can build out bits and pieces of the business logic in .NET and utilize it from your Classic ASP code until you're ready to re-write the UI in .NET as well.
I agree with what Justin said; if you have a working application in place, you'll need a compelling reason (i.e., money) to justify the expense in rewriting the application for a new platform.
Although ASP classic and ASP.NET share a similar-looking syntax and some common coding conventions, they are very very different from each other. If you tried to simply copy-paste classic ASP code into an ASP.NET application, you might be able to get it to work, but you'd be missing out of a lot of the advantages of ASP.NET Web Forms or ASP.NET MVC (and their respective frameworks, of course).
You can, however, extend the functionality of the existing site with .NET code through web services or COM interop. We have a 10+ year old classic ASP web site and I've used both .NET web services (.asmx) and COM-callable .NET DLLs to enhance our existing application. In both cases, I wrote all of my new business logic in the .NET component and provided a chunky interface to work with the existing ASP page. That allowed my .NET code to be very easily testable and still use our existing (huge) investment in our classic ASP site.
The only approach that has worked for me is to carve of areas of functionality in small slices, and rewrite. "Converting" first, then refactoring seemed like a good idea a few times, but in the end just became horrible messes of code written in ASP.NET instead of ASP - and that added no value.
If you have a site that has distinct areas of functionality, carve one off and start with that (I chose "contact us"). Write it the way you think it should be written - that is, assume your new part is fitting into the end design of your well-written app. If you have to add "hacks" to interface with the old system, make sure they are isolated and commented.
When working on an update, think "can I carve of some of the functionality here into it's own bit?" - if so, convert it then update it. I found that if you insist on keeping the NEW app clean and allow yourself to add small hacks to the OLD app for communication, you get the best results.
This does mean you'll have two separate apps (two IIS web apps) for a while, and can make cookie/url and session management a bit hairy, as well as adding one more deployment concern. To combat this, make sure that you minimize state in your web app (always a good idea anyway), and share state through something other than Session.
If you do this a piece at a time, make the pieces small enough, and have a good design up-front, this works well - at least in my experience, it's the way that works best. Note that my experience may not match reality.
I'm developing a website , job portal. I have 2-3 years of ASP.NET webform development experience,
I want to create a professional job portal site (to improve and learn more) but trying to decide on best architecture. Any suggestions or advice will help...
Thanks
Well, there are a number of ways to answer this question, and I'm sure many others will chime in. I'll just say that since your goal is to improve and learn more, and you already have 2-3 years of webform experience, this might be a good opportunity for you to learn MVC. Then you will have experience in both, and can make more informed decisions regarding the best architecture for future projects.
Happy learning!
Whilst nobody can tell you exactly what to do, the team I manage is about to release a new CMS / Job portal using ASP MVC. MVC gives us excellent testability and scalability out of the box and it can be quickly combined with tools such as nHibernate / windsor (IOC) / nCache / jQuery - this ensures that you have a wealth of resources on the internet to help accelerate your development and skill. You can also embrace standards such as XHTML 1.1 strict, which is almost impossible with ASP.Net webforms due to the auto generated HTML
1 other advantage is that you also get away from the dreaded ASP.Net viewstate.
Use ASP.NET MVC if you want to:
learn the ASP.NET MVC framework
use jQuery or similar libraries
really learn web-languages (HTML, CSS, JavaScript)
use Test Driven Development
have a clean separation of concerns
If you don't have the time or will to learn to use the ASP.NET MVC framework correctly, stick with ASP.NET WebForms.
My answer is almost always "ASP.NET MVC." The amount of flexibility and features and testability and maintainabilty and ... heavily outweigh WebForms.
WebForms has the advantages of a rich ecosystem of existing controls and documentation, and is really powerful for some kinds of tasks (complex, multi-form interactions), but I find its limitations get in the way far too often. You have to mold yourself to it.
It really depends on what the end goal of the application is. As Scott Ewers said, if your goal is to learn, then using ASP.NET MVC will expand your breadth of knowledge in the ASP.NET space (since you already know web forms).
Additionally, if this is going to be a public product, you can leverage the testability benefits of MVC and run automated unit tests. Key ideas like Separation of Concerns can also increase long-term scalability and maintainability.
The primary reason why you might choose web forms is if you are rapidly prototyping the job board application. As you know, web forms allows you to drag-and-drop components onto the canvas to quickly create some basic data entry functionality.
There is a herding code podcast from May 13 on the subject.
Herding Code 47: Joe Brinkman on Webforms vs ASP.NET MVC.
I also agree that choosing MVC would have the advantage of allowing you to expand your knowledge. That not being the only reason, given the choice as well I just finished a small MVC project (my first) and let me tell you MVC rocks! Its a great framework which I feel gives you more flexibility and at the same time out-of-the-box tools to create a web app quickly and painlessly. It was my first experience with VS2008 & .NET FW 3.5 & LINQ, and all the guides at www.asp.net helped me go forward quickly (especially the free tutorial chapter from an MVC 1.0 book mentioned here).
I also got to learn JQuery along the way, as it is very much integrated into these new technologies.
One think to take note though is that this being a new tech, version 2 is already being cooked up, so if your project is for the long run, have that in mind and plan accordingly (in my case, being a small project, I'll probably try upgrading my project to version 2 when its officially released). Yet at the same time, having a fully MS (and thus MSDN) supported version 1 was a godsend for me...
Good luck!
I have good experience in Jquery, CSS, HTML, Javascript but not in TDD.
I have time..and willing to learn MVC but wasn't sure MVC is good choice for Job portal or similar site..
This can be considered a shameless self-advertisement but here is my quiz on how to choose between the two:
http://sietch.net/ViewNewsItem.aspx?NewsItemID=101
I was recently tasked by one of my clients to write a paper, or simply a checklist, that would help other lead developers make this same decision.
I posted the first 2 rough drafts on my blog. I am admittedly pro-mvc but the paper/checklist has been we received so it might be helpful.
http://eric.polerecky.com/archives/a-somewhat-less-biases-comparison-of-mvp-and-mvc/[http://eric.polerecky.com/archives/a-somewhat-less-biases-comparison-of-mvp-and-mvc/][1]
I think the most often overlooked benefit of MVC is convention; I really see any convention in webforms projects and while not strictly enforced in MVC projects at least its there.
i started developing our current app in webforms, mvc wasn't available when development started.. i've chosen the MVP pattern, with URL rewrite HTTP module. currently i'm investigating plugging in some MVC into this, basically to use the front-controller instead of using page-controllers. the other things in already established MVP architecture with web forms in my app give me more flexibility than pure MVC approach without WebForms, which i like, although require a bit more code than MS MVC examples (never tried it for real project to see if it stays that way, like in those examples in screencasts).
what i don't like with MVC is mixing control code inside templates - i believe loops, ifs and stuff like that just shouldn't belong inside the template. but a couple days ago i've ran into Spark view engine that looks kind of promising in that segment, although not still close to the Tapestry 5 (a component-based webGUI framework) in the java world.
But the above mention suggestion to mix both might work for you to explore MVC world and have the safe ground to fallback to if something won't work for you might be ok for you.