I have an ASP.NET application that has two very large folders within the application on the production side: One for images and another for App_Themes. They grow dynamically from user input and customization. There are similar folders in my dev application, which have only some sample data for testing.
I am using web deploy through Visual Studio 2010 to publish my site to the production server. I have changed my .csproj file settings to exclude these two folders from deployment and have also checked the "leave extra files on destination" checkbox. However, the publishing still takes a long time. I think the reason is related to web deploy checking all the files in the images folder and the App_Themes folder on the server.
Is there a solution that would solve the publishing problem? I would like to continue using web deploy because it is really practical compared to other methods of publishing. The server is running IIS 6.
You can publish the way you're doing it, but into a local directory. It should be quick that way. Then set up a robocopy job ( http://en.wikipedia.org/wiki/Robocopy ) to sync the local publish directory with the web server. Robocopy can be fired off via a .bat file (I bet you can even chain it somehow to the completion of the publish) and is very configurable allowing you to specify files or directories to omit.
Related
So I'm using visual studio 2010 to build a website that was formerly running on PHP, so I'm pretty new to the environment.
In starting the project I built a website project, not a web application project. I know that will probably generate a lot of "never use a website project, use a web application project instead" comments, but bear with me.
I'm attempting to provide our server team with the necessary files to compile on our server for the first time. However they're used to working with web application files, not website files.
Normally they are given the source code and a batch file that compiles the code into deployment directories and then they just move the files to the server from there. I'm pretty sure that the other teams use deployment packages to do this, which obviously isn't an option for a website.
My question is, what would be the equivalent steps for getting the source for a website ready to deploy vs a web application? I have published the website to a separate folder and this has rendered what I think is the equivalent in many ways, but I wanted to make sure.
Also, is it possible to publish certain parts of a website without others?
Please with-hold all the comments about how I should be using a web application instead, google seems to assume that's all that's used out there too.
Thanks!
There isn't much to deploying a web site other than copying the source files to a directory in IIS. It will compile the site automatically on the first page request.
I agree with Britton. I personally prefer web application but with the web site project you have 2 options.
Either a) Upload all the files (including the .vb or .cs files) and the web server will compile on the fly. OR, you can publish to a separate folder locally on your machine, and then upload that folder. I would do the publish if you don't want anyone seeing your source code.
I have an application that is installed at several different client's servers. They each have different web.config files and different virtual folders. At the moment I am compiling, manually copying over, setting up IIS, changing web.config and adding virtual folders for each install and also again when updating.
I simply don't know how to deploy using something like Web Deploy or Deployment Package that will let me create different config files or how to manage virtual folders (I would assume I would simply deploy empty folders and would still have to do this part manually). I can handle setting up IIS and virtual folders from the start but I want each client to be able to download new versions and install them without my input (as some Clients are funny about remote access).
You can setup build configurations for each environment. Typically, you get Debug and Release out of the box. I like to replace those with Development, Staging, and Production configurations, which allows a different web.config per environment.
Of course, when publishing, you still have to make sure you select the correct configuration.
I'm not a fan of Web Deploy and other schemes because web-servers, unlike desktops, all tend to have a unique configuration.
In my case, all of our web applications are deployed with custom-written VBScripts (much more pleasant than Batch files and without needing to relearn PowerShell). VBScript (with its default COM object library) provides a compelling platform for writing deployment scripts. And if you can't stand the syntax you can use JScript using the same tools. Bonus: Visual Studio still provides Windows scripting IntelliSense despite it not being an advertised feature).
My most recent deployment script is simple: it's a VBScript (invoked by VS's Post-build command-line) that uses 7-Zip to pack up the web application's files, then generates an ftp.exe batch file (then runs ftp.exe itself) that uploads the files to the server, it also generates an uploads a file called "Unpack.cmd" which calls 7-Zip to extract the files into the right place. The only manual step is executing Unpack.cmd on the server, but that can be done with Remote PowerShell, for example.
Why do you need to customise your IIS configuration separately from the application? Can't you put everything in your web.config file under <system.webServer>?
I have an ASP.net that I built in VS2010 running in iis7 however when I go back into VS and make updates to the code behind file and re-publish the application still acts as it has before I made the changes. I have tried deleting and republishing all the files and restarting the app pool but it still doesn't affect how the application behaves.
project-->Property's--> Package / product web--> Items to deploy --> All files in this project folders
now publish your project.
your new files also added in publish folder. . .
DO NOT publish your vb and cs file on there server unless you feel like having your source code potentially exposed. There have been multiple vulnerabilities that have allowed code download.
Publish the application to a folder via the visual studio publish menu.
On the server, go into your temporary aspnet folder for example:
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
and find your app and delete it. If you cannot delete the files stop the worker process (w3wp.exe) or restart iis.
Republish and all should be good. If you are in doubt if that version is getting executed then add some logging in the new version or trace information.
There are two options for publishing an ASP.NET site to a server:
Copy the .aspx AND aspx.vb (or .aspx.cs) files to the server. The first user to hit the server causes compilation so it takes a little bit of extra time for them. Once that's done, subsequent hits should not be impacted.
Copy just the .aspx files - and a compiled DLL to the server. The DLL contains the compiled code so it doesn't exist on the webserver. The first user does not have to wait for compilation and the VB or C# source code is not on the server, potentially accessible to hackers.
It sounds like you've compiled the site to a DLL but that DLL isn't getting published to the server when you re-publish. Have you recompiled the site before publishing?
I faced similar issue with WPF single file exe publish.
while debugging from VS my changes were visible.
But when I pasted the exe to deployment folder, the changes weren't there.
I had to change the version number to see my changes when I run the exe from the deployment folder.
I may have to do with how single file exes are handled. The extracted cache may not be getting updated.
Currently we deploy compiled ASP.Net applications by publishing the web site locally and emailing a zip file to the system administrator with a (usually) lengthy set of instructions for deployment. This is because the first time we deployed an ASP.Net application to a customer the dev and test IIS instance were the same, and we were unable to deploy the site twice to the same machine. This set the tone for deployment on all subsequent projects.
I am now evaluating our deployment methods and am looking specifically at the built in deployment tools; specifically I'm looking at custom installation tasks and using as much of the standard installer functionality as I can (mostly the user interface).
Secondly, I'm looking at merging deployments and automatic updates.
How do you go about deploying sofware in your organisation? What tools do you use, and what problems do you come across most frequently?
We have dedicated DEV, TEST, STAGE, and PRODUCTION servers.
We also have a dedicated build machine which runs Cruise Control.
Cruise Control is configured for a Continuous Integration build, which runs after code is checked in. It is also configured for separate Development, QA, Stage, and Production tasks.
To deploy to development, the code is first retrieved from SVN and built, then the "Precompiled Web" folder is copied to the development web site, and the web service project is copied to the development application server. Cruise Control is also configured to "tag" the source code before the build starts so we can reproduce the build at a later time, or branch from the tag if we need to do a hot fix.
To deploy to QA, the files are copied from the development machines to the QA machines.
Likewise, to deploy to Stage the files are copied from the QA machines to the Stage machines.
Finally, to deploy to production, the files are again copied from the Stage machines to the Production machines.
To configure each environment, we have a custom tool which is part of each environment's Cruise Control task that modifies connection strings, "debug=true|false", "customErrors=Off|RemoteOnly", and other environment-specific settings.
So each environment can be deployed with a button push from the Cruise Control dashboard.
One caveat is that we currently have the production database password configured in the Cruise Control config file...it would be nice move it elsewhere!
Lastly, let me add that even though our production machines are in a dedicated hosting facility, the servers are accessible from our Cruise Control machine, which makes it very easy to do a production deployment. The only manual step is to encrypt the web.config files and remove the "AppOffline.html" file that Cruise Control puts up.
Let me know if this helps, or if you have any questions.
Thanks!
A couple things that I have done is the following:
1) Use a Web Deployment Project in order to compile and clean the build as well as handing web.config section replacement if the config changes between environments.
2) Use NAnt to do all of the building, archiving, and copying in a repetitive manner.
The Web Deployment Project ends up creating a MSBuild file which can be used in place of NAnt; however, I came from a Java background and used Ant all of the time so NAnt is my preference in .Net. If you add in the NAnt Contrib tasks, you will be able to deploy not only the files but also handle items such as your source control (incase it is not part of the default tasks) and Sql Script Execution for changes.
Currently I use both of the options together. I have my NAnt build file call the Web Deployment Project through MSBuild. With the configuration manager setup for each environment, it allows me to manage the web.config section replacements automatically and still have fairly decent control over my copying and archiving of a release.
Hope this helps.
We use web deployment projects, and the VS 2008 projects to create an .msi from the output of the webdeployment & other projects. A normal windows app called 'setup' is used to do a lot of the db creation and preliminary stuff, rather than trying to customise the setup projects with custom steps. It is a lot easier to do this yourself than trying to customise the MS code. This windows app then calls the correct .msi files that the user needs.
Team foundation build runs every evening to rebuild the solution and copy everything to a 'Release CD' directory which anyone can access and do testing on the latest 'release'.
To be honest TFS build is a bit overboard for a small team like ours, and I only use it because its what I am used to.
In a previous company we used this http://www.finalbuilder.com/ and I can recommend it for ease of use and for the amount of software supported.
1) Build project with MSBUILD
2) FTP files to Production Environment
3) Copy / Paste manually to each web server
For intranet sites, we use CruiseControl in conjunction with SVN to have the site rebuilt automagically.
Theoretically you could extend this model over a VPN if you could map a drive remotely to a client's intranet. Or a more quick and dirty solution might be to use a tool like SyncBack to sync the remote folder containing the compiled DLLs for the site.
Deploy Web Applications Using the Copy Web Tool
Text from Microsoft Training Kit Book Web Based Development
Web Setup Projects are useful if you are providing a Web application to many users (for example, allowing people to download the application from the Web and install it). If you are responsible for updating a specific Web site for your organization, it’s impractical to log on to the Web server and install a Windows Installer package each time you make an update. For internal applications, you can edit the Web application directly on the Web server. However, changes you make are immediately implemented in your production Web application, and this includes any bugs that might be there. To enable yourself to test a Web application, you can edit a local copy of the Web application on your computer and publish changes to the production Web server using the Copy Web tool. You can also use the Copy Web tool to publish changes from a staging server to a production Web server, or between any two Web servers. The Copy Web tool can copy individual files or an entire Web site to or from a source Web site and a remote Web site. You can also choose to synchronize files, which involves copying only changed files and detecting possible versioning conflicts in which the same file on both the source and remote site have been separately edited. The Copy Web tool cannot merge changes within a single file; only complete files can be copied.
Is there a security risk associated with using the option that copies "All project files" when publishing a web application into a production environment? I normally use the option "Only files needed to run this application" which does not copy the source code to the server.
I am the only person with access to the production server. There is also no issue with cluttering the production server as there isn't much on it. In fact I don't mind having all the source files be kept on the server together with the binaries.
Is there any security issue with this?
If no one can get access to the production server then there is no security risk with this option. However this is a pretty big if! I can’t see any real benefit from using the All project files or All files in the source project folder options – these don’t even allow you to update the web application in place on the production server which might be useful in some situations. I would stick to the Only files needed to run this application option just to be save.