I recently finished a personal web application I had created for my uni. It's mine now to do with as I want. I wrote it on Visual Studio using ASP.Net, CSS, and C#. (I had originally written the first few pages in HTML and PHP, but due to a problem with my computer's inability to run XAMPP, the PHP pages weren't running as required so I redid it on Visual Studio)
The project's initial functionalities (uploading media and documentation, and login and user registration) are there and the pages work, and I plan to proactively work on it to add more features and make it more dynamic and versatile.
However, I have a question, what can I do with it now? Is there a platform (maybe Stackoverflow itself?) that I can upload the project as a whole on to add it to my technical portfolio? or maybe another such action I could do to upload or publish it to add it to my list of things done as a reference for recruiters, or as part of my project history for graduate school?
Related
I have created a new ASP.NET (.net framework) website (not core) and when i run the project i get the following files created in the bin folder - website.dll, website.dll.config, website,pdb.
1) Are these always created for websites?
I would prefer not to have them because when i want to make a change to a .cs file the dll needs to update which will reset all sessions.
2) How can this be done?
I have previous asp.net websites and these files never got created so i am a little confused. old net versions don't do it?
FYI Project settings - .NET Framework 4.7.2 and the output type is class library (other options are console application and console application.
You have two types of asp.net webform projects.
A)
A asp.net web site.
These sites are thus not really a visual studio project. When you create a asp.net web site, then you don't use file->open->project, but use file->open web site.
With such above site, each asp.net page will have a corresponding cs, or vb.net page for the code behind. And you can modify ONE page (say the markup, or code), hit save, and you are done. Such pages (and the code) is compiled on the fly by IIS (the web server).
A lot of people do like the above setup, since in many cases, if the web server is on your same network, you can open the live site directly. Make some changes, hit ctrl-s, and you are done. Of course EVERY page used thus results in a .dll being created.
So, above is still a option you can use (and what you likey were using in the past)
However, there is a 2nd choice,
Asp.net web site application.
The key word/term here is "application".
In a asp.net web site application, then you have a standard sln (project file), and you have to re-build and re-compile the WHOLE site before a new update or deploy.
this means that even changing ONE line of code behind forces you to do a FULL re-deploy of the web site. However, while this is somewhat more "pain" for a new deploy, it is still a far more controlled environment. This choice also means that visual studio (vs) does the compiling BEFORE deploying.
There are significant advantages to this setup. You can include multiple projects and assemblies (and get FAR BETTER compile time resolution). So, the more advanced a developer, the more say using git, and adopting use of class library's and objects?
And the more compile time checking, and the more you adopt class objects and liraies for your devleopment cycle? The more you perfer the applcation approch to software development. As noted, there is that ONE BIG penalty for the enjoyment of far better managment of referances, compiling, and management of a larger project - you lose the "one quick and dirty" deployment option.
So, you have to pre-compile the site/code, and then run it. IIS does not do the compiling (and more important than the management of those other external code libraries). In most cases, with a web site, to add new assemblies to your project, the .dll's will be placed in the bin file. (and I don't like that at all).
I far perfer when I do a clean project, that the WHOLE bin folder and ANY dll's are 100% blowen out of the water, and don't exist anymore. If you use a web site, then you will and MUST have a hodge podge of .dll's strewn all over the place. And EVERY single page with code behind creates a .dll.
So, while your hands are somewhat "more tied" with a asp.net web site application, from a developer point of view, the advantages far outweigh the additional work/effort to deploy.
I have zero, but BEYOND zero idea why you feel or don't like the idea of all of your referenced assemblies at compile time being managed for you, and they all get compiled, and placed in the bin folder for you. Be it a desktop applcation, a console application, or whatever? The hallmark of the compile process was and is to gather up all of your referenced assemblies and .dll's and dump/place/compile/manage/put them into the bin folder for you.
Better yet? When you publish, you can choose options to "merge" all of the .dll's into one dll. This really is much like using a linker for software development.
The other big advantage, is you can say develop with new rosyln compile features. (free form text for sql is really nice). Since vs is doing the compile for you, then you do NOT have to ensure that the web site and IIS requires the advanced compiler options.
So, much of which one you perfer comes down to:
Do you value developer features, better compile time resolving of assemblies, having VS compile the code for you, or do you want to toss out the code to the web site, and have IIS do the compile?
The above also means that your web site will require the source code when using the web site option. This can be someone of a issue for some developers, or even security. Since any modifying of such web pages will automatic trigger IIS to re-compile that page + code for you.
With a asp.net web site application, then no server IIS compile of your code occurs, and better yet, at compile time the .cs (or vb) pages are stripped out, source code is stripped out, and the source code pages (code behind) NEVER is placed on the server. You thus ONLY get the .dll's and the source aspx pages, but NOT the source code pages published on the server.
As of vs version 2022, BOTH template options are supported. So, if you want to use or go back to use web site as opposed to application development? You can make that choice. Just use file->open webs site, and don't use the .sln (project file) anymore.
And you can when creating a new web site choose "asp.net web site", or choose the preferred (by many) the "asp.net web site application".
So, for a lot of sites - especially those a bit older, often developers choose the web site option - the deployment and update is really far less hassle and is done with far greater ease then a application choice. Despite this greater ease of making small updates to the web site, I still far prefer the application choice, since it has far better options in terms of referencing, compiling, and just overall general application management features. Might not matter for your case, and if the current site was a web site (not web site application), then I do suggest you continue and keep that code and site "as is", as opposed to converting to a application.
It seems strange that your panties are all twisted up over having some .dll's appear in the bin folder at compile time, as opposed to a HUGE MOUNTIN of .dll's created for EVERY web page + code behind as what occurs when using a web site.
This compile time and dumping of .dll's into the bin folder? It how all console, desktop, and more .net applications has worked for over 20 years of .net. Can't possibly be a surprise to any .net developer, and in fact most will be confused and miss this approach to software when using a web site - since now IIS is doing the code compile - and not you nor is visual studio.
So above should clear up the difference between the two choices, and why you are seeing a different behavior from past projects. Sounds like that past project was a web site, and not a web site application.
In my company we have to develop a ASP.NET MVC 5 web application which must have a number of plugins.
We want these plugins to have the following features.
Each plugin can be deployed in a separate folder; No need to copy plugin assembly to bin folder, the plugin files keep same structure as an ordinary website;
Dynamically install/uninstall plugin after website gets running;
Plugins share same master/layout;
I have found an article that describes a similar solution, but it depends on plugin framework which is based on OSGi.NET which is not open source.
Is there a plugin framework that has the above features?
Yes. MEF is very good.
This is example of how to build MVC website with plugins architecture:
http://www.fidelitydesign.net/?p=104
http://www.fidelitydesign.net/?p=130
I had the same task few weeks ago and now I have working solution, so ask, if you have more questions.
UPD
In my case I want users to be able to add extensions to the app without any dependencies or configuration files. All you need to do is copy extension's folder into the main project's extensions folder. Each extension might contain dlls, views (in separate views folder), content (styles, images etc). Moreover, each extension might have one or more db types support and this can be configured with just copying of files too. Also, my app contains some backend, and this backend should be extensible with the extensions too. So every extension have to tell the main application what it can offer for the frontend and for the backend.
I have spent a lot of time for this, but now it works very good.
I have an existing solution in VS2010. When I click the properties of my project I get the view as can be seen in image1.png:
When I create a new empty ASP.NET web application and click the properties of my project I get the view as can be seen in image2.png:
A huge difference.
Now I'm implementing this code here: http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api
And that tutorial assumes I get a view as I've shown you in image2.png
In image1 and image2 I've also marked the menu items: "Website" and "Project"
This makes me assume that I've created a website application whereas I need something different (I'm thinking a web application project).
Not sure what to do now, I need to convert my current application to another thing, but to which type and how to do it?
I also came accoss this post: http://blogs.msdn.com/b/webdevtools/archive/2009/10/29/converting-a-web-site-project-to-a-web-application-project.aspx
But before I start screwing up everything :P Is that what would solve my problem?
It should be possible to use either a web site or a web application project. In the example on the link you've posted, they use the predefined template for ASP.Net MVC Web Applications. This has several advantages - it sets up the structure and other resources for you - it's effectively a template.
For the purposes of the tutorial, why don't you just set up an application that way? If you've already written some code, you can just import it into the new application.
For future projects, you might want to consider which is best for your needs. Apart from structure, there are some other key differences between a web application and a web site project.
MSDN handily provides the differences here:
http://msdn.microsoft.com/en-us/library/dd547590.aspx
If you find you want the features of the web application, then the link you've posted is fine. You'll need to do some re-organizing of your references and so on and so forth, but the process is fairly straightforward (but not painless).
A "web site" in visual studio is the old, .net 1 style of creating web sites. It basically dynamically compiles the code in a folder when it's hit for the first time. Later .NET introduced a "web application" model where the code is compiled into a DLL and no code files are deployed with the site. "Web sites" are pretty much depcrated and shouldn't be used for any new projects unless you're doing a quick demo site.
The codeplex project you referenced also depends on MVC 3 (which are web applications).
You are probably better off just restarting like the tutorial says - create a new MVC application like it shows in its first screenshot.
If you do not have that option, use Web Platform Installer to add MVC for you - http://www.microsoft.com/web/downloads/platform.aspx
Good luck!
I can't tell exactly what's going on from your screenshots, but if you have a web site that you need to convert to a web application project, you can find the directions here
Although the instructions are specific to VS2005, they are basically the same for 2010 as well.
Which Visual Studio template should be used for a ASP.NET web site, the Web Site template or the Project | Web Application template?
you'd better read this:
http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx
in my opinion it depends on what you are developing
Both function and perform similarly, but still differ in following ways:
Web application:
We can't include C# and VB pages in single web application.
We can set up dependencies between multiple projects.
Can not edit individual files after deployment without recompiling.
Right choice for enterprise environments where multiple developers work unitedly for creating, testing and deployment.
Web site:
Can mix VB and C# page in single website.
Can not establish dependencies.
Edit individual files after deployment.
Right choice when one developer will responsible for creating and managing entire website.
Web application projects works more like a traditional VS project, which has a project file, is compiled in one step and so on.
Web site projects works more like classic ASP or PHP-sites. There is no project file (references are stored in the solution file), and pages are recompiled dynamically on the server. The nice thing with web sites is that you can just ftp to the server and change a file in a text editor. You dont need VS. Some may hate that, though.
It probably depends on your background. If you are used to ASP or PHP style development, web site projects will seem more natural to you. If you have a traditional application developer background, web application projects will seem more natural.
If you're using Team Foundation Server for source control, you'll probably have to use a Web Application Project, as you need a .csproj file.
There are more details from Jeff Atwood himself: Web Site Projects vs. Web Application Projects
Web Site web projects are particularly painful in Team System due to the lack of a physical file that contains project information and metadata. For example, it's impossible to check in code analysis rules on Web Site projects, because the code analysis rules are stored entirely on the client!
I prefer a website. A website is a collection of files in a directory. It becomes more portable and deployable. A web application clouds the issue with a project file.
Personally I use web application projects exclusively now. I actually converted a rather web site to a web application because of compilation times for the web site.
I also use pre-build events to move configuration specific configuration files around and pre-build and post-build events are not available in web sites.
In Visual Studio 2015, I've come to somewhat prefer web site projects over web app projects. I still use visual studio though because you get Nuget Packaging, you can install nuget packages to both types of projects.
However a WebSite Project does not have a project file, you are literally just adding a folder to your solution.
However you can still have code, but I prefer to put it in a separate project.
In WebApp projects you have your Assets, Css, Views (razor, aspx etc), Controllers/Code Behinds etc all in one project and it just mashes together. I prefer to work with websites in two halves. The front end (css, js, images, "html/cshtml/aspx/ashx/.master/etc") and the back end (all the code).
So I create a Web Site project and a class Library to accompany it (in visual studio you can add references to the web site project). I add my class Library as a dependency and all Code is in the class Library. You can still have a global.asax, you just have to tell it that the code behind is in another dll (not the one that the site will compile to). MVC views, you just specify the namespaces like normal (the dll is referrence so the namespaces are there). And in WebForms you Just have to remember to include the assembly name with your type references that the code is in.
It's a little tedious to get use to, but when you do you have isolated structure, everything is in a place that makes sense and modularized in an easy to maintain way.
And the PLUS side is that because the Web Site is just a folder (no project file) it can be opened in Visual Studio Code easily, and other popular text editors making it easy for designers to work on the css/js/images etc (which are not in the code project). Keeping the layer designers separated, the designer sees just what they need to see.
Now structure wise. I keep my code local on my machine checked into a subversion repository using Tortoise SVN and Visual SVN (java/.net shop). To test locally I install IIS and I set the website project up in IIS locally just like I would on the dev/prod servers.
Then I install MSDeploy on the dev/prod servers and I use the Publish web app feature via MSDeploy in visual studio and I use web.config transformations. So I have web.config transformations for dev and prod and the main web.config without transformations is for local testing (so it works for all devs on the project).
To previous stated cons: Having a WebSite Project vs a WebApp Project doesn't mean multiple developers can't work on it, that's only if your WebSite Project is on some server some where and you are loading it directly from there which would be bad practice.
You can treat a WebSite Project just like any other Visual Studio project, local code, source control, multiple developers.
As a final note, an added benefit of separating your code is you can put all of your code in a shared project. Then you can create a Class Library for each port you might do, say one on straight .net 4.6 and another on .net core 5 and link in your shared project. As long as your code is compatible with both, it will build and you don't have any duplicated code files.
This question already has answers here:
ASP.NET Web Site or ASP.NET Web Application?
(25 answers)
Closed 3 years ago.
When creating a new ASP.NET project in Visual Studio should I chose create: website or project?
I understand that web application project was the way to do it back in the day with VS 2003 but is it still applicable today? What are some of the caveats using one over the other?
There's a pretty good comparison chart on MSDN.
Website projects are simple, in that all files added to the project folders are automatically compiled and included, which was supposedly added to make it more palatable to classic ASP and PHP developers. Once benefit is that it includes build providers, which allow for certain actions to be associated with a filetype - that's how the first release of SubSonic would rebuild the data access layer when you added a .abp file to the site.
Web Application Projects are a lot more flexible, though. For instance, all class libraries in a Website Project need to be in the App_Code folder, which is frustrating in a complex application. There are a lot of scenarios which just don't work for a Website Project.
You can convert from one to another, although if you're unsure I'd recommend just starting with a Web Application.
I strongly disagree with some of what the Websites and Web Projects article says.
First, it wasn't any "small" group of developers who rebelled - I'd suggest it was most of us, who had not been asked if we wanted to totally change the way we developed. They certainly didn't ask me if I wanted to lose six weeks of development time figuring out what they did to break a perfectly good web service.
It wasn't some "download" MS released - it was VS2005 SP1, and they released it pretty damned fast.
In their plusses for projectless development, the "Copy Project" command works very well, and we don't have to avoid debug or project files; you can move pages around - if you don't use source control; where do they get that you have to lock the project files in order to collaborate? What are they using for source control?
I'd also add one question to the debate: what's so special about web sites that they should be the only "project" type (as far as I know) that doesn't use a "project" file? I can't think of anything, unless it's that Microsoft thought that web developers were too simpleminded to understand projects.
Of course, if anyone knows of any other Visual Studio "project" type that does not use a project file, I'd be grateful to be informed of it.