I intend to use the web deploy feature of ASP.NET 4.0 for my site. Does anyone know if this feature does incremental deployments (i.e. only deploy changed or new files in the solution)?
Thanks
MSDeploy does deploy only the new or changed files by default. But I've stumbled upon this question when I had found that for me it wasn't the case. I was using Angular CLI that copies the assets folder as-is, but file dates are lost on the way. And MSDeploy by default uses file dates to determine if a file had changed.
Here I've found a way to force MSDeploy to use checksums instead of file dates. You just need to add <MSDeployUseChecksum>True</MSDeployUseChecksum> in your first PropertyGroup in your .pubxml file (publish profile). Or, if you don't use a .pubxml file and use msdeploy directly instead, just supply a /p:MSDeployUseChecksum=true argument when invoking it. Works like a charm for my temporarily slow internet connection: reduced the deploy from 10 minutes to 10 seconds (most of the assets never change). Yay!
Yes it does. It is really fast, also for solutions with many directories.
I've seen the deployment time of a big solution being reduced from 30 minutes to about 5.
For smaller projects, the incremential deploy is done within seconds.
Edit:
Due to several call backs: Have a look at this screenshot:
Check out the radio buttons. (The image is taken from an article about web config transforms, that I've written in the past. Check out this link if you want to see the context of this screenshot)
Related
I'm maintaining a webforms application for several different clients in Visual Studio 2008. Each client has their own separate web.config file. We are using config transformation when deploying which works great.
There are many developers currently working on this project, and while developing each developer needs to have the configuration values for a specific client. Right now, what we are doing is that each one of us, has their own version of web.config locally, and we just try to be careful not to check in the web.config file.
This approach of course has several drawbacks. We need to do this manually, which is annoying, we need to be really careful not to check in the config files since it could cause trouble for the rest of the developers, it's cumbersome to add a new value to the config, etc.
I'd like to transform the config files when building from visual studio, so we can chose which file to take the configuration values from, without having to manually edit web.config.
I've been looking in the web for a while, but the best thing i found so far is this:
http://www.codeproject.com/Articles/399002/Project-Build-Web-config-transformation
Which is not working for me, it gives me a build error saying it can't copy Web.config_output because the file is missing.
By default tools like SlowCheetah and other config transform technologies use the $(Configuration) to figure out the name of the transformation to apply. You could take the slowcheetah.targets file and edit it to take $(username) which will pick up the standard windows logged on user name if you're building inside visual studio. You could use a condition to apply the change specifically when '$(BuildingInsideVisualStudio)'='true'.
This will require you to do some work with MsBuild target files, but the end result would be that your developers can check in a web.jesse.houwing.config (in my case) and that of that file is there, their transformation will be applied instead of the standard release or debug transformation.
As for a good starting point, look at SlowCheetah.
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.
I am developing an asp.net website that will need regular updates for source codes and HTML sides. After i have completed the necessary updates, i use the 'publish website tool' and publish the site to my local directory. Then i upload all files to Remote File. Is there any way to fix my site with just changed files. For example if i have updated just 2 files of 84 (HTML or source side), is it possible to update just this 2 files without any problem?
While Visual Studio does offer a few different compiling/build options, I think that you are probably doing everything just fine for a Visual Studio Website project. When I'm working with a website rather than a web application, I will only FTP the files that have changed. For example, if I were to change some HTML tags around within an .aspx page, then only that page would need to be uploaded to the web server. If I change the Page_Load function in the .aspx.cs page, then I will definitely need to get the updated DLL on the web server as well.
I use FileZilla for my FTP tool and there is an option to only upload the changed files. So after you use visual studio to publish your website, you can grab the entire contents of that directory and drag it over to the FTP server location and only update what has changed.
The ASP.NET website project offers an option in the Project properties -> "MSBuild Options" tabpage where you can set "Allow this precompiled site to be updatable".
Setting this option
"Specifies that the content of .aspx
pages are not compiled into an
assembly; instead, the markup is left
as-is, allowing you to change HTML and
client-side functionality after
precompiling the Web site. Selecting
this check box is equivalent to adding
the -u option to the
aspnet_compiler.exe command."
according to the docs.
I've been entirely underwhelmed by the available tools to VStudio. And am instead using Gulp.
Even in 2017 the problem remains.
With gulp you can "watch" directories for changed files, so I have it configured to watch the [bin] folder, along with assets separate from aspx/cshtml files.
That way whenever I change anything, it is instantly copied to my publish folder where I can later zip it up and deploy ONLY the changeset. The script even has a delay so I can delay the copy/upload in situations like bundles where they are generated dynamically and take some time to be fully modified.
The only thing I have to do is clean it up before I start my next milestone, so that the "publish" folder which gulp "auto deploys" to is empty and ready for the next run. Emptying a folder and running "gulp watch" in background seems like a small price to pay for such a needed feature.
I feel like this should be a good item to develop as a vstudio plugin.
Recently I have been forced to move to a windows/C#/.NET/MVC environment from linux/node/angular. Sigh. I found the following solution (next paragraph) elminates the pain caused when using visual studio to "publish" the code. The VS2017 publish process copies every file in the entire application to the web server, even if just one character is changed in one file. This can take over an hour for our moderately sized app.
So here's what I do. I first publish the solution locally (typically to bin/release/Publish/). That takes about 1 minute as opposed to 1 hour to publish to the server. Then, I compare the files between my local Publish directory and the server directory using FreeFileSync. FreeFileSync is amazing -- and free. I have access to the server directory via a windows file share. The compare takes about 15 minutes. I can then see exactly what files are different and need to be pushed. Note, the option I use compares the actual CONTENT of the files, not just the create time. I then use the FreeFileSync sync feature (mirror option) to copy the few files needed to the server. This takes maybe two minutes. So the total operation takes about 20% the time Visual Studio "Publish" takes. But best of all, the actual hit on the prod server is only the two minutes it takes to copy the diff files, rather than the 1 hour outage inflicted by Visual Studio Publish as it slogs along copying each and every file.
It depends on the type of project.
If is a project created with File > New Web Site then is ok to just copy the changed .aspx files (make sure that the corresponding code - .cs - files are also copied).
If the project was created with File > New Project > ASP.NET Web Application then you will need to copy the .aspx files and the compiled project dll (by default the dll has the same name as the project like TestProject.dll) from the bin folder inside the project.
i think you need something http://winmerge.org/
where it will compare files that are changed and upload them.
hope this helps
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.
I am working with couple of friends on an ASP.NET MVC website. The project is maintained in SVN and I have CC.Net set up to checkout latest version and do automated build and deploy to a pre-production server. The default build configuration is set to Debug, but the automated build is set to build Retail. Everything works just fine, except for the <compilation debug=""> in web.config which currently is set always to true. I'd like to be able to specify true or false for <compilation debug=""> based on the build flavor.
I've thought about two separate solutions to this problem.
I could have a pre/post-build step that modifies the value. However, the web.config file is under source control, so modifying it in the automated build will leave it checked out on the build machine. I could also have additional step that would revert it as well.
I could also instead of having web.config under source control, have a web.config.base file that is used as a source during the build to generate the web.config file. The problem with this approach is that most of the tools modify web.config directly and we have to manually merge such changes back in the base file. And since there's no indication when any tool changed web.config, we have to look for changes at any checkin. Not only this becomes a tedious manual step, but it's also error prone.
Both of these approaches would work, but have some shortcomings. I was hoping there's a more elegant way of doing this. Thus the question - how do you guys deal with modifying web.config that is under source control during the CI builds?
You can take a look at the Web Deployment Projects VS add-in. Scott Guthrie does a great job explaining it in this post.
Why not modify web.config as part of a build-step using a command line utility that can edit XML?
e.g. Obtain a command line utility that works like:
xml_mod.exe web.config [xpath-of-value-to-change] [new-value]
Then have different value per debug/release(retail)..
Why don't you just make the web.config read/write without checking it out from source control, make your changes you need during the build process and then discard them?
AFAIK SVN has the files read/write anyway.
we have a
web.config for development
web.config.cert which is deployed by hudson to our cert environment
web.config.prod which is used for production
This allows us to put comments in there and values in there specific to the environments when that would normally have to go in some documentation somewhere, and it would surely be ignored.
Like I said, we have Hudson deploy to our cert environment on each build, so it just copies the directory over, deletes the web.config and renames web.config.cert to web.config
You may want to check out Hudson, I dont think I've ever heard of anyone choosing CC.net over Hudson if they had the ability to choose :)