I want to reuse a project developed in vb.net in c# webform project. The login form should be same for both the projects. How can I achieve this? Can I add vb.net and C# forms in single project.
If created as separate projects in single solution, can I share the session variable between two projects?
I want a common login form for c# and vb.net project. Need to share user credentials between two apps
Well, you can intermix pages of vb and c# only if the web site is NOT a web site application.
So, it kind of depends.
If your web site is setup as a website application? Then no, you can't do this.
You can certainly take any of the code modules, classes, and business logic from the vb.net applcation, and refreence such assemblies in the new c# project.
And its not really recommended to do this anyway (ie: mix both types of pages in one project - but, you can do this for a web site, but not for web site applications).
I see VERY but VERY little advantage to simple re-writing all that code. It not like your going to get more features, or anything of value here.
If you looking to migrate to .net core, MVC etc? Then again, those pages could not be used anyway - even if they were written in C#.
So, either you consider this a migration project out of webforms (and .net 4.8), or you don't. Anything in-between is really a waste of time and resouces. If that site is to continue running as webforms, then I can't really make the case to migrate the code to c# - I just don't see any benefits here.
So, this can work for a asp.net web site, but not for a asp.net website "application".
And, I always hands down preferred the "application" choice, since then things like including other projects and code (often written in c#) can be used and is supported.
But, a page with code behind in vb.net, mixed in with pages and code behind in c#? No, you can't do this with a web site application, and giving up the application choice (vs that of a web site) I think is too high of a price to pay in that you lose out of the benefits of a asp.net application choice in the first place.
This sounds like good money after bad. Unless you going to migrate to a newer framework? It makes VERY little sense to spend time + money to migrate to JUST c#, and I can't see any real benefits of doing so.
if the developers in question know well asp.net + webforms, then the learning curve to maintain the site "as is" with vb.net? I can't see more then a day or so for any good c# developer to get up to speed with vb.net.
c# or vb.net is really moot - what matters is a good solid skill set in the .net framework, and unless you jumping over to .net core, then as noted, I can't see how the cost of this work can be justified. it in effect amounts to stealing money from those paying for this conversion, and that means someone is being mislead, or miss informed here.
I need to write some functionality to present on a sharepoint site which needs to work with a back end sql database. I would also like to leverage the core functionality of this 'component' in a standard ASP.net website. I am a newbie with SharePoint and especially with old version like 2007, is it best to do this as a webpart or a user control. What would be the benefits / drawbacks of each.
Appreciate any guidance / links to other materials.
thansk
if you create user controls you will be able to use them in another project - the drawback is that SP2007 is ASP.net 2.0/3.5 as is SP2010; but in Asp.Net you can take full advantage of .Net 4.0 and above.
A User control - specifically designed as a standalone control will be re-usable in more projects so make sure you add it in its own project rather than wrapping it up into the SharePoint Web Part project.
If I have to make a choice then at that moment I will prefer the User Control.
There arae mainly two advantages of that.1. You can reuse it in any other project if it will require same functionality like this one.2. As Mauro said SP 2007 is Asp.net 2.0/3.5. You can work with that one too.
AS you are a new bee in sharepoint you can work with the asp.net more easily then wrapping it in the sharepoint web part object.
hope my answer help you in decision
I'm on the point of starting a medium scale web application and I'm considering developing using ASP.NET Razor syntax Web Pages framework (not MVC). But as I've seen many people consider "Web Pages" to be tailored towards beginners.
I'm developing professional large scale web applications in ASP.NET Web Forms for several years now, but I've always inclined towards clean html/javascript code more than server side controls therefore I find Razor syntax very much appealing. I'm using Visual Studio and not considering web pages for helpers functions or other beginner eye candy features.
Having this in mind what are your opinions on scalability, speed, long term development on this approach?
In terms of performance WebPages is asp.net and gets compliled so performance should be similar to WebForms and MVC.
I'd say that any site that could be built using ClassicASP, PHP or WebForms (without using server controls) can be built just as well using WebPages.
I prefer WebPages over WebForms and MVC for my sites. You get full control over the HTML, don't need to worry about concepts like the page lifecycle and postsbacks unlike WebForms. On the other side you get a lightweight, simple framework where you don't need to use VS.net, solutions files, project files and 3+ files to serve up a single page and you don't need to compile the entire solution before deploying unlike MVC.
But what you use I think depends mostly on your detailed requirements and skillset.
But as I've seen many people consider "Web Pages" to be tailored towards beginners.
Go for the ASP.NET MVC 3 and the Razor view engine then. It provides you with the WebPages syntax coupled with the full power of the MVC pattern built on top of an established platform such as ASP.NET in terms of scalability and long term development. You can't dream for better as far as the Microsoft stack is concerned.
I am starting a new project in VB /.Net Framework 2.0 for a company corporate website with data driven forms. So should I go further with Asp.net MVC or Asp.Net web forms and WHY ??? We are not ready for Ajax now but later.
And also we have DevExpress components.
Actually I see ASP.NET MVC as next generation in that it is an evolution - trying to be a better programming environment, as software development for web apps asks for something more testable.
It is a huge beast. Decide based on features whether you need it. MVC has less documentation and is a lot harder to master thanks to a less RAD approach, but it seems that once you are in, it will be quite a better experience. If you have a web application (like stackoverflow.com) then it may be a good approach.
DevExpress components - have fun... throwing them away. Like most ASP.NET components they will not work or only work very partially. Totally different approach.e
ASP.Net MVC is not "next generation" ASP.Net. It's an alternative approach to design that can be more beneficial depending on the kind of project you're working with. Without more information about the particular type of project you're working on no one can give you any informed recommendations.
We are about to embark on a large enterprise application. I am seriously considering using ASP.NET MVC because:
We need to use Microsoft technology (biz logic is all C#)
Performance is critical
I'd like to test as much as possible
My team has only used PHP for web development, but are very experienced with .NET winforms (so either way we have a learning curve). My concern is that some people have expressed concerns about ASP.NET MVC's scalability to large apps. But from what I read webforms have their own problems as well.
Should I be reconsidering webforms, or stick with my gut and use ASP.NET MVC?
Related:
Should I build my next web app in ASP.NET MVC?
https://stackoverflow.com/questions/521388/from-webforms-to-asp-net-mvc
ASP.NET webforms are heavyweight and drop a crapton of stuff on your webpages, both in html/javascript and serialized viewstate. I remember my first ASP.NET website causing the GC to blowed up because of all the short-lived objects being rehydrated from that godawful viewstate. Oh, when I was young and naive (i.e., 2 years ago)... You have to have a very good understanding of webforms to build scalable websites from them. Possible? Definitely. Easy? Not.
ASP.NET MVC is harder to code initially, but is SO much easier to develop than webforms. The hardest things to learn are 1) the conventions aka "magic strings", 2) Html + inline code aka ASP and 3) html forms.
With MVC, you can't get away with the state nightmare that is so common to webforms development, which means that means your webpages are meth-addict slim. It also means you have to code your state a little smarter. The code is also MUCH simpler and scales MUCH better than traditional webforms, imho.
Also, testing with ASP.NET is near impossible, due to the hard-coded and unmockable dependencies baked into the framework. ASP.NET MVC replaced all of these with System.Web.Abstractions members that are mockable wrappers around these badly-designed and untestable objects.
Run, don't walk, to MVC.
For the obvious-impared, if you use a framework that sits ontop of the ASP.NET framework, such as MVC or any other that you wrote or that somebody else wrote, OBVIOUSLY some of these remarks don't apply.
If, on the other hand, you code as early man did against the ASP.NET webforms model (e.g., Response.Write() in Page_Load), my comments apply.
Can you write code that's testable against ASP.NET? Sure. Can you do it without including special testing code you or somebody else wrote? Sure. If you have TypeMock.
ASP.NET WebForms is very much like Winforms and allows for RAD (rapid application development). It's very fast to get something in no-time. Problem with this is testing can be a major pain and if used for anything public facing can mean some major issues with ViewState. WebForms can hold state making things like a wizard a breeze to use.
ASP.NET MVC on the other hand can take a little longer to develop with and requires that devs understand how HTTP works. It's a stateless architecture meaning each request is it's own little world and usually has no knowledge of previous requests. The framework also allows for high testability.
As far as performance goes they're probably the same because ASP.NET MVC is just a framework built on top of the existing ASP.NET architecture. Though for client-side experience I'd say MVC is a bit faster.
As far as scalability I would say they're about the same as far as technical goes. How as for using the API and integrating it MVC would probably be a bit easier.
The website you're using right now to ask this version question is built on ASP.NET MVC and they have 2 web servers and a beefy db server.
ASP.NET MVC is not a problem for Enterprise, but neither is ASP.NET, Silverlight, etc. They are all UI technologies. The majority of your application logic should exist in libraries beneath the UI layer anyway, so pretty much any UI can be used.
We need to use Microsoft technology
Performance is critical
I'd like to test as much as possible
Based on the above, ASP.NET MVC will work. But, you can move the code down below the UI and test. If your algorithms are below the UI, you can tune them without altering the UI. And, if the UI layer is very thin, the perf hit for the UI is negligible.
No. One thing that the ASP.NET MVC has over ASP.NET Web Forms in terms of performance is that it doesn't make use of a control tree. The control tree consumes a lot of server side memory and keeps the garbage collector very busy on pages with many controls. I would argue that you would get superior performance from the ASP.NET MVC. The unit testing aspects of it are a real win to.
The flip side of this is that you can't use all of the handy out of the box controls that you get with ASP.NET Web Forms and you'll probably end up doing more client side JavaScript development so the initial development budget would probably need to be greater if you choose ASP.NET MVC over Web Forms, but you would have a superior solution for the long term.
Stick with your gut. ASP.NET MVC helps facilitate testing because almost the entire API derives from interfaces.
Have used WebForms for years and never liked them. Now use Asp.Net MVC for some years and this is so much better. Certainly woud recommend MVC.
Asp.Net MVC has an excellent architecture and is open source. So if you would identify bottelnecks in the http processing chain you could fix it. Most time you would be able to fix performance issues using one of the many extension points provided by Asp.Net MVC, like Binders as an example.
I would say go with MVC if you need or want its features . If you are building a line-of-business application such as an ERP or CRM system, I would use Webforms; if you are building a portal or community wiki type site I would go with MVC hands down. Ultimately it comes down to preference and what exactly your enterprise application needs to accomplish.
"With MVC, you can't get away with the state nightmare that is so common to webforms development, which means that means your webpages are meth-addict slim"
Upmodded for that quote!
My opinion: use ASP.NET Webforms.
Disable ViewState in the Web.Config.
There is no need to preserve state because everything you really need is in the Request object.
Use Javascript in conjunction with AJAX for data retrieval to render your UI controls client-side.
Create serverside wrappers in the form of control tags for your client-side component renderer.
This is how I've been working for ages now, and it's fast, reliable, testable and organized.
It does take some time to setup a decent framework for this working method, but eventually it will rule.
I rather have no spaghetti code like MVC. Been there with PERL/PHP and classic ASP.
Everything I've read about asp.net MVC says that it is able to serve up more page requests than asp.net webforms.
I have some doubts about its stability and security though. Both of these stem from the fact that it's not even released and even with the RC we saw some changes to the framework. I am sure there will be more changes as time goes on and things are found. It's new so there are not really "best practices" out for it and there is a not a wealth of experience out there detailing the small issues or gotchas that you might run into.
I've been using it and it does result in smaller pages and faster performance. But there are so many things I can do in webforms that I have no idea how to do with mvc because mvc does not promote the use of the webforms controls.
If you're able to use stored procedures then you don't need a big middle-tier like those generated by MVC. All you have to do is pass XML to your stored procs through a simple HTTP handler, get results back from a stored proc, and convert the results to JSON. MVC and other middle-tier stuff only serves to make money for companies that sell IDEs like VS.