I have a solution in Visual Studio 2008 that contains three projects: a C# Library and two ASP.NET Web Sites (call them A and B). Web Site A depends on the library, and Web Site B depends on Web Site A.
This means that if I make a change to the library project, I have to build it, then publish A, and then publish B. Similarly, if I change A, I have to publish it and then publish B in order to push my changes through.
Is there any way to make this a one-click process for the entire solution? Basically I'm just looking for a way to, in one opaque step, build the library, build/publish A, and then build/publish B.
I have looked into the Web Deployment Project option and it does not do what I need - as far as I can tell, it kind of does the opposite (highly customized build & deployment for a single web site, rather than pretty much default-config building/publishing for multiple projects all at once).
I believe that Web Deployments projects will work for multiple projects within the same solution.
http://weblogs.asp.net/scottgu/archive/2005/11/06/429723.aspx
If you look at his examples, you can see that he has a website project or WAP as well as a C# library within the same solution, and he seems to be able to compile and deploy them all together.
You could probably also use multiple WDP within the same solution configued to do multiple things.
Basically the best way is to forget clicks and make this single-step deployable from the command line. Check out MsBuild to build the solution, then possibly the aspnet_compiler for build/deploy usage.
Related
I have a client who has a large existing application written in ASP.NET, which is setup as a website project in Visual Web Developer 2010 Express.
I have been asked to demonstrate how to write unit tests and to help configure the Hudson build environment to run these tests automatically.
The code is reasonably well structured and although it does not use any UI patterns there is good separation. Business logic tends to sit inside separate classes rather than within the .aspx or associated code-behind files.
Nevertheless, as a website project rather than a web application, DLLs are not generated so the tests we have written cannot be run by the NUnit GUI.
I would like to be able to run the tests before check-in.
I would like to run the tests automatically as part of the continuous build process.
I cannot change the project type to a web application as there are downstream processes that are dependent on the project type.
Whilst upgrading to Visual Studio Professional is being investigated, I have to assume for the purpose of this exercise that I will need to make it work on VWD.
What are my options to achieve this, given the constraints above? Is it even possible?
TIA
I have a ASP.NET Web application which has 2 projects (one for UI and one for Business layer).
Now when I publish this for deployment, it's giving me so many DLLS in bin folder which starts with prefix "App_Web...." in the name. How can I make it into only one DLL or 2 DLLS (one for UI and one for BL)? I work with Visual Studio 2010.
I believe that these are the result of pre-compilation. If you turn that off, you should stop seeing these.
EDIT: A bit of research into how to do this suggests that you're likely using a Web Site project for your UI. If this is the case, consider re-creating it as a Web Application, and I think you'll be set.
I am trying to a create an installer for my web application. My solution contains several projects. They include:
Class library project (referenced by the web application)
Web Application
Windows Service
Web Services project
Database project (execute update script)
I also have an unmanaged dll (crystal reports) in my web application project, so I might have to do some editing of the registry.
I ideally want to be able to use a web setup project to install the whole solution. Can this be done? Is there a better method/solution?
The short answer is "Yes" it can be done.
Other better solution? Well, I'm not a huge fan of VS.NET's installer/setup, can be kind of bulky, 3rd parties could be better at a price. Having said that, it should be able to satisfy your requirements.
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.
I'm trying to create a standard way of rolling out web applications for our company. Currently we do it with zip files, vbscript/javascript, and manual some steps.
For thick client installs we generate MSI installers using Wise/Wix. We don't create installers currently for websites as in general they are just xcopy deploy. However we have some config files that need to be changed, verify that certain handlers are registered in IIS... The list goes on.
Do most people use MSI installers for web applications as well, or some other tool/scripting language?
I recently spent a few days working on automating deployments at my company.
We use a combination of CruiseControl, NAnt, MSBuild to generate a release version of the app. Then a separate script uses MSDeploy and XCopy to backup the live site and transfer the new files over.
Our solution is briefly described in an answer to this question Automate Deployment for Web Applications?
Do consider MSDeploy, that is the direction Microsoft will be investing in the future for deployment of web applications...
Know more about the future direction at Overview Post for Web Deployment in VS 2010
We have been using FinalBuilder (www.finalbuilder.com) for this purpose for long time and for some time also using InstallAce (www.Installace.com) for build deployment on the Web Farm.
You may want to look at:
How do I get a deployable output from a build script with ASP.NET
Step by Step ASP.NET Automated Build/Deploy
We use MSI to create basic installers for our web projects too, often using the Web Setup Projects in VS and sometimes completely custom installers. You may also want to look at MSDeploy.
We're moving to an MSI for our installs, so far with mixed results. I'm a control freak so I would personally prefer a series of scripts that I had more direct control over. I've used ANT in the past with good results.
Have you checked out NAnt and CruiseControl?
Combined, they can provide an easy and automated way to build and deploy your web apps.
I work for a state agency and we do all our deployments using a product called RepliWeb.
It works good because as dev's we have no control over the webservers. But we can deploy to a deployment area and run the RepliWeb job to do the deployment. Not sure on pricing though...