Forgive my ignorance, though I am new to this. I've search a lot but can't seem to come to a definite conclusion, so any information is appreciated.
So to the question: Is there a built-in configuration for web site publishing in MS Visual Studio called "Release"? The reason I'm asking is that some have told me it is, but I can only find the "Debug" configuration in Visual Studio.
So, if there's supposed to be a "Release" as well, how can I get it or can I manually add a new equivalent?
Go to the Solution Explorer (CTRL+W+S), then find your project. Right click on it and go to its properties. Find the Build tab. The top of the window will contain the active build configuration for your project. You can then change from debug (the default) to release.
By default, projects have two configurations: release and debug. You can make more, but first learn more about those two. The most important differences are explained in the question linked by Nacho in the comments. Good luck and happy codding.
edit: Web Site projects don't have the Release configuration available, but it makes no difference since they are not compiled. Web Application projects, on the other hand, do get compiled and have both configurations available.
It's been a long time (~4,5 years), but I think I might have used a Web Deployment Project for a Web Site Project once, for changing config files (replacing by copying from another directory) (xml node: WebConfigReplacementFiles)
I used Web Deployment Projects before web.config transforms where invented. (If you are interested in web.config transforms, check out my tutorial for VS 2010: http://www.tomot.de/en-us/article/5/asp.net/how-to-use-web.config-transforms-to-replace-appsettings-and-connectionstrings)
Another useful link might be: http://msdn.microsoft.com/en-us/library/377y0s6t(v=vs.100).aspx
Related
I am working to setup a build server using Team City to build and deploy asp.net web applications to a staging site with transformed web.configs automatically. Everything is working except that the code that ends up on the website (the aspx files) have the HTML in them when you open them in notepad.
Before all of this I was using web deployment projects with websites, and the code was compiled. If you opened one after it was deployed, it said it was a marker file.
I have tried some tutorials on how this process should work, but the code always ends up in an editable state (the html).
My question is:
What do I need to do to get MSBUILD from the command line to ultimately have precompiled code on the webs server?
Any suggestions, links, pointers, or ideas would be very helpful to me.
You need to invoke the aspnet_compiler tool to do this. There are some limitations or complications depending on exactly what you need to do for things like strong-naming. The MSDN article here has pointers.
I used to have MSBuild project steps that did this, but we decided to drop precompiling because our clients want to integrate our product into their internal portals, and precompiling made things complicated for them.
Are you using MS Web Deploy? I use it regularly for automated deployments from my Team City Build server to dev, staging, QA, etc. And I'm transforming configurations as well.
If you want to check out this alternative you can follow the excellent guide by Troy Hunt:
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html
I have a solution with a fair few projects, 3 of them web-based (WCF in IIS / MVC site). When the solution builds, it dumps each of the components of this distributed system in a 'Build' folder. Running the 'configurator' part of the whole output will set up the system in the cloud automatically. It's very neat :) However, the Web Deploy Projects are a major pain. They "build" (i.e. deploy) every, single, time I build - even when no changes have been made to their respective projects.
Changed a single line of code? Look forward to waiting around a minute for the 3 web projects to redeploy.
[These projects are VERY straightforward at the moment - two have a single .svc and one .ashx file - the other is an MVC app with ~5 views]
I realise I can change solution configurations to not 'build' them, but I've been doing that and it's very easy to log on the next day and forget about it, and spend a couple of hours tracking down bugs in distributed systems due to something simply having not been built.
Why I use Web Deploy Projects? Well, because I need all pages + binaries from the web project. The build output for the project itself is the 'bin' folder, so no pages. The entire project folder? It has .cs, .csproj and other files I don't want included.
This will be building on build servers eventually, but it's local at the moment. But I want a quick way of getting the actual output files from the web project to my target folder. Any ideas?
Not sure if this will help in your situation, (plug for own project coming up), but I am working on a project to help ease IIS deployments:
https://github.com/twistedtwig/AutomatedDeployments
The idea being you can use config files for IIS (app Pool, applications and websites) to automate the creation and update of sites locally (dev machines) or remotely (test and production machines).
It is still a work in progress but is ready to be used in production systems.
using the package creation as a post build step might get you closer to what you want, (don't believe it includes all the extra files), but that would still build it each time, (although if code hasn't changed it should not rebuild unless you choose rebuild all projects).
In the end I created a utility/tool which, given a project file, XCOPYies the project folder for the web project to a target location, then looks in said project file and deletes anything that doesn't have Build Action set to Content. Very quick and effective.
I know it is still in RC but VS2012 does have a neat feature when doing publish that it detects the changes and publishes only those. Might be something a little deeper down in the build where it does an automatic publish too.
You can take a look to the Octopus project: http://octopusdeploy.com/
Deployment based on nuget packages.
Just wondering what is the best option for deploying an ASP.Net Website.At the moment I just place the code in a folder on server and create a virtual directory on IIS referring to this folder. Then I open the website in VS2008 on the server and build it.Though it works fine for me,I am not sure if I am following the best approach for deployment or not.
Thanks.
There's a wealth of opinion on this across the internet and it is all opinion. To an extent it's down to you and your team (if you have one), if your approach is working for you then I don't see any huge reason to change but I would suggest that you at least have a staging site where you can deploy the code for user testing before it's deployed to production.
That said, running VS on the server isn't great (and means you need another VS license so could be a waste) and as VS includes a Publish option anyway, it's rather redundant. I use publish for the smaller sites and it works a fine.
Publish from inside VS is a pretty powerful tool as it lets you do web.config substitution. Check out the Hanselman talk Web Deployment Made Awesome: If You're Using XCopy, You're Doing It Wrong
You have several options which are preferable to running Studio on the server.
Depending on your team size, you could:
publish right from VS
continuous integration, check out Cruise Control for info on that
combination of CI and file synch (i.e. CI to test server then xcopy to production)
I'd advocate for CI since you tend to find issues faster that way, but it assumes you are using good version tracking and testing practices. Copying files can have unintended consequences like missed files, outdated files begin retained, etc.
When you deploy that way, anyone who gains access to the web server (which may be beyond your control if it is hosted) can view and possibly even alter your .aspx pages.
One alternative, which you can use from within Visual Studio, is to compile everything into a binary. You do that by choosing menu Build > Publish > uncheck the checkbox "Allow this precompiled site to be updatable." The downside of this, of course, is that even the tiniest change in a page's HTML will require recompiling the code and redeploying it.
It's a clear tradeoff between security and manageability, but precompilation can also aid in performance. Here is one explanation of precompilation alternatives.
You might also consider the suggestions made in Key Configuration Settings When Deploying a Web Application. In a nutshell,
If you are deploying your web application to a machine that you have control over, such as a web server within your company's intranet or a dedicated web server at a web host provider, you can use the element in machine.config to force all applications on the web server to adhere to the recommendations provided above (namely, using a custom error page, disabling output tracing, and not having the auto-compiled code compiled in debug mode). Simply add the following markup to the machine.config file within the <system.web> element:
<deployment retail="true" />
Again, this is a pretty simple change to make.
On a project I work on, we originally built on a dev machine, zipped and copied the contents of the 'bin' directory across. (unzipping, creating a site in IIS etc...)
Later, when we had the time, we went for this approach:
Creating windows installers in VS2008.
This has worked really well, as (literally) anyone is capable of doing the deployment. The real beauty of this, is that you can account for This is just a fancy way of wrapping the process of copying the 'bin' directory across...
Food for thought I hope.
Dave
In my line of work I'm often retrieving very specific versions of crusty ASP.NET web apps from their long-forgotten repositories, making minor changes and then recompiling.
A major annoyance in this process is having to create a virtual directory for every web project that I need to recompile. I don't have any problems with the process, but it's tedious and still a very manual process on .NET 1 projects.
Is there a fairly simple way to recompile the binaries of the csproj without setting up a new virtual directory?
Edit: I don't mind using command line tools, or external solutions, as long as they're fairly simple and straightforward.
I'm not sure there's any other way unless you can convert the project to vs 2005.
I ran into a similar issue when i was dealing with a web project that i needed to manage a few branches that all wanted the same virtual directory. I wrote this small app that does some switching of the virtual for you automagically.
I have added on to the app to make it more functional (supporting more than just one project at once)... and i'm sorry to say i have never update the code on the blog. This might just serve as a good starting place for you to manage your virtual directories.
I will try to get the latest code up on the blog soon and i will update this post when i do.
but in the meantime check out the source here
ps. i know this version of the code needs to be cleaned up this version was just a proof of concept.
Is it possible to exclude a folder in a web project from being published? We've got some documentation and scripts that included in a particular project folder, and are added to the project, but when I do a VS publish, I don't want them to go up to the production server.
I know they shouldn't be in the project, but I thought I'd find a workaround before I try to convince the owner to modify the way he's doing things.
Old question, but I found if I mark the folder as hidden in Windows Explorer, it doesn't show/publish in your solution.
This is good for example to stop original photoshop images being included in uploads which aren't used and are big. Anything more complex though you'll probably want to write your own publish tool.
This doesn't answer your question, exactly, but my feeling is that unless you are a single developer publishing to a server, you would be better off doing builds on a dedicated workstation or server using MSBuild (or some other building and deploying solution) directly (and thereby would be able to very granularly control what goes up to production). MSBuild can not only build, but using some extensions (including open source types), it can also deploy. Microsoft has a product called MSDeploy in beta, and that might be an even better choice, but having no experience with it, I cannot say for certain.
In our situation, we have a virtual workstation as a build box, and all we have to do is double click on the batch file that starts up an MSBuild project. It labels all code using VSS, gets latest version, builds the solution, and then deploys it to both servers. We deploy exactly what we want to deploy and nothing more. We're quite happy with it.
The only downside, if it could be considered a downside, is that at least one of us had to learn how to use MSBuild. VS itself uses MSBuild.
For the files you don't want to go, loop at the properties and set the 'Copy to Output Directory' to 'Do not copy'
This option is not available for directories, however.
Can you not exclude them from the project through visual studio to stop them being published. They will the still exist in the filesystem
The only way that you can do this to my knowledge would be to exclude it from the project, do the publish, then re-include it in the project. That can be an issue.
There are probably much better ways to solve this problem but when we publish a build for our dev servers, we'll run a batch file when the build is complete to remove the un-needed folders and web.configs (so we don't override the ones that are already deployed).
According to http://www.mahingupta.com/mahingupta/blog/post/2009/12/04/AspNet-website-Exclude-folder-from-compilation.aspx you can just give the folder the "hidden" attribute in windows explorer and it won't publish. I tested this and it works for me.
Seems like a straightforward solution for quick and dirty purposes, but I don't think it will carry through our version control (mercurial).
Select all the files that should not be published.
Go to Properties
Set
Build Action -> None
Have to repeat the process for each sub-directory.