I'm attempting to use Web Deploy to Publish a Web Application.
I want Visual Studio to delete any files that no longer exist, so I've checked the "Remove additional files at destination" setting in my Publishing profile.
However, I want VS to ignore the /Content/uploads folder, as it contains contents that my users have uploaded. Naturally, the contents are different in my development site than they are in the live site.
Unfortunately, I have been unable to discover a way to make Visual Studio ignore this folder when publishing (it wants to delete all of the content, since it doesn't exist in the project).
Does anyone know of a way to exclude specific folders on the target site from being examined by Web Deploy?
I had a similar problem, wanting to keep some files in the deployment package even though they're not part of the project.
Try to create a custom MSBuild target for this, that works for me.
Here is a Getting Started MSBuild reference
Hope this helps.
All the best.
I was unable to find a suitable solution for this issue, so I've created my own:
https://pubsync.codeplex.com/
PubSync enables quick and reliable file syncing for publishing Visual Studio projects.
Related
When I publish a site on existing one where I created multiple webjobs, this deletes all the files on server and all the web jobs are deleted.
I assume this is because webjobs are stored in App_Data folder. When the APP_Data directory is deleted, the jobs are deleted.
How can I avoid deleting the app_data folder when doing a publish?
A third option to Andy's answer would be to deploy you WebJobs with your website, just make sure the WebJobs scripts go to the right place which is under app_data\jobs\{job type: continuous/triggered}\{job name}.
See more about deploying WebJobs: http://blog.amitapple.com/post/74215124623/deploy-azure-webjobs/
I noticed this as well and can offer the solutions I came up with.
If you are publishing from Visual Studio you can deselect the file publish option "Remove additional files at destination". Of course you are now no longer deleting unused files on the server which probably isn't ideal.
The other option is to simply create a second website just for your webjobs. You can leave the site blank, you don't need to publish anything to it or configure anything beyond the webjobs. One advantage to this approach is you can monitor (and potential scale) the webjobs site separately from your original website.
The solution I found was to exclude publishing to the App_Data folder.
If you are publishing using web deploy from Visual Studio 2013, you can enable this option as follows:
Right-click on the web project.
Click Publish...
Click on Settings
Expand File Publish Options and check Exclude files from the
App_Data folder
Close and save changes.
I have a home machine and office machine I use to publish websites using Visual Studio 2013. If I make a change from the same machine, and re-publish, just the changes are published, not all files.
However, when using my clone machine at the office, even if I do a get latest, make one small change, and re-publish, all files are published, not just the ones that changed, and not just the ones that have been recompiled. ALL dll files, even third party dlls that have not changed or have been recompiled with a new date, are republished. Same thing happens if my cohort publishes a small change on his machine after I did the last publish. Not a problem if publishing twice from the same machine as then only the changed files are published.
Is there anyway to prevent complete republishing just because a different machine is used to publish than the one used for the last publish? Thanks.
This seems to make "Determining Changes" a lot slower, but for .Net 4.5 [and
up(?)], use this info from:
https://msdn.microsoft.com/en-us/library/ee942158:
To configure Web Deploy to use checksums instead of dates to determine
which files need to be copied to the server, add the following element
to the .pubxml file (Publish Settings):
<MSDeployUseChecksum>true</MSDeployUseChecksum>
Like this:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<MSDeployUseChecksum>true</MSDeployUseChecksum>
<!— other settings omitted to keep the example short -->
<PublishDatabaseSettings>
<!— this section omitted to keep the example short -->
</PublishDatabaseSettings>
</PropertyGroup>
</Project>
First of all, I do not understand the behavior of MSBuild+VS2013 and the publishing feature completely as I just started to use the publishing feature myself. I'm looking for a way to speed up publishing via FTP web deploy in VS2013. (I'm not using TFS for a get latest though.)
I would say this is partially explained in a different context at this SO question. The MSBuild process. Timestamps of certain files are being compared and then could indicate MSBuild/VS2013 whether a target (build output) is up-to-date or not. Then files that are not up-to-date are being recompiled.
As you all work on different machines, timestamps are likely to be different quite soon.
To find out what is actually going on during builds/publishes, set build output verbosity to detailed or diagnostic, for a moment:
VS2013 menu - Tools - Options... - Project and solutions - Build and run - output verbosity - set to -> detailed or diagnostic. Run the build, and see the Output panel/tab in VS2013. Select "show output from: Build" to see results if not already visible. Don't forget to set it to the original setting after checking the build details, as it could slow the build down a bit.
But why even unchanged third party dll's are being republished? Possibly because these dll's ARE actually overwritten during a build. You might have the assembly reference property "Copy local" set to true to get your website running without any manual uploads to be done for this. Or you are using a commandline copy command with the overwrite parameter explicitly set to true during project's post build event (like 'copy /y ...' or 'xcopy /y ...'). Then the timestamp of the file that is to be published is overwritten for sure, see in
the "obj\Release\Package\PackageTmp" folder (or for example: "\Debug" instead of "\Release" if Debug build is set for the selected publish profile.)
Furthermore, VS2013 as default does NOT check timestamp differences on the targeted webserver if you are using FTP publishing, at least that is my experience. As for the other publishing options like a web deploy I don't know yet. But the differences you experience seem normal behavior to me, as you run builds on different machines and publishing files from different machines as well. So timestamps are likely to be different... which, again, indicates 'changed' files to be published.
As I'm curious how this question should be solved, I was looking for this in the first place:
Maybe a TFS build server is an option for you, configured with a rolling build. But I read on a specific SO (sorry, can't add more links at this moment as I've just registered) that is suggesting to do clean builds to prevent new problems. And that will force full publishing again as files are all being changed by the clean build... so that won't work I think.
As an answer, you might want to use these FAQ answers on MSDN for web deployments. See the questions:
"Can I exclude specific files or folders from deployment?" .NET 4.0/4.5 and/or
"How to make Web Deploy use file checksums instead of dates to
determine which files were changed?" .NET 4.5 only!
The first option is to exclude files.
The second option is to use a checksum to compare files instead of timestamps, but that could be somewhat slowing the build(?) process, as the FAQ says. Note the first few lines on that FAQ pages, on how you can edit your publishing profile to apply one or both of these elements!
Also it is an option to put the thirdparty dll's in a different project which you then could only include that project in the deploy for a certain solution configuration (VS2013 menu - Build - Configuration Manager, see the checkboxes in the 'deploy' column there for every project. Though I'm not sure if this is part of the VS2013 'publish' feature as a web deployment, because this deploy column checkboxes are greyed out for my solution projects for some reason I don't understand yet... so I can't test it to verify this option.)
Though it sounds logic, don't forget to create backups/copies/screenshots first before you change any settings or publishing profiles, and then change the same settings/configurable files on the other machines you and your colleagues work at.
I know IIS allows the creation of Publish Profiles that can be "imported" into Visual Studio in order to upload a site directly into IIS (since I'm already using it).
But now I have a more specific question regarding the use of these publish profiles in Visual Studio.
I have a solution for a web application that comprises a couple different components that I'd like to keep sepparated in IIS.
Namely, I have the web version, a mobile version and a couple webservices in this project.
What I'm configuring the server to do is have the webservices, mobile and website separated into different sites and use different publish profiles to publish them, each into it's own place.
Since I have all of these components into a single visual studio project, would it be possible to have publish profiles that publish a single component of the project without requiring me to do a "full publish"?
Or is the only solution to have separate projects? (even if they are all in one single VS Solution)
Visual Studio's web publishing feature assumes that projects map to atomic components1. There isn't a way by default to specify how to only publish a subset of the project. Partly this stems from the build system (MSBuild) that the Web Publish Pipeline (WPP) is built over.
Options you can investigate:
Make your site contents match the structure in your project. Deployments are incremental (if coming from your machine), and you can deploy specific files or folders from the VS Solution Explorer. If you need to republish your binaries, you're still stuck doing a full publish. Publishing individual files/directories is the exception to note 1 above, and only works for content file changes.
If you're up to the challenge, you could dig your way through the WPP targets (it's all MSBuild), and try to find a way to restrict which files are published. Then you could set up separate publish profiles within your project that each only handle a subset of the files.
The easiest way, especially if you're automating this, is probably just to use separate projects for each component. :(
We are using VS 2012 with TFS 2012.
We want to prevent some users to view particular source files in a project,
We know how do this,Actually by right clicking on the files on the source control window and manage permissions in security tab.
The problem is that when we prevent a user to view or change a file such as HomeController.cs
the user can't build the project and the vs IDE says that the file does not exist,
How we prevent access a file with the ability of successful building project for the user
If you prevent read / view permission then how can the compiler access the file in order to build it? If the compiler can see the file then so can the user.
Are you sure that you want to prevent these users from even seeing the file, or do you just want to prevent them from changing the files? If it's the latter then you can simply remove the permission to check-in.
There is another avenue that may be of use in your situation. Split the project up into libraries and only combine all the libraries on the build server.
The developer can build but not run on their machine. With gated check-ins the build is made available.
This works especially well if the project is web based and the build server deploys the assemblies to a web server that the developer can view.
Otherwise the notes on obfuscation and decompiling stand.
I have a larger solution that I desire to distribute via ClickOnce. It consists of one main shell executable that directly references only a small subsection of libraries and processes that constitute the solution.
The solution consists of a few other processes and several libraries (some C++). I need to be able to include all of these libraries and processes in one ClickOnce distribution for both local builds and TFS server builds.
I cannot reference every other library and process form the shell project. And I do not wish to push these files into a MSI to be treated as a prerequisite as it would defeat the purpose of using ClickOnce to distribute/update the product.
What is the correct method to incorporate all of our necessary files/projects into a single ClickOnce distribution?
The IDE won't detect native DLLs as dependencies when publishing, but you can run the SDK tools directly to include them manually in your ClickOnce distribution. You can either use mage.exe in your post-build script or run MageUI.exe to have a wizard to guide you through the package generation.
Suggested reading:
Walkthrough: Manually Deploying a ClickOnce Application
Understanding Dependencies of a Visual C++ Application
There is an alternative to Visual Studio for this kind of situation. You could try using Mage, but it can be a little tricky to use. My company wrote an alternative called ClickOnceMore.
ClickOnceMore is a ClickOnce build tool for when you don't want or can't use Visual Studio to do ClickOnce builds.
There is a specific page on the UI for including files (using rules to include anything from a single file to an entire directory trees) so you should be able to do exactly what you need with it.
This is what I have done in a similar situation. I use TFS at work, so convert the terms to whatever you may use (or not use) for source control.
I have a main workspace that I use for all development of my application, I keep this workspace pristine.
I then created another workspace with a proper name (ex: solution-deploy) and in this workspace I do the following:
Get latest and merge everything from source-control into the deployment workspace
I build a Release build of my application
I r-click on the root (I put them in the root, because I need to access them from there, put them in whatever folder you want) project folder for my deployment project and select "Add -> Existing Item"
I browse in the file selector to the Release directory of the assemblies I want to add to my deployment package, select them, then I use the arrow next to the Add button and drop down to "Add As Link", do this for all of the assemblies you want to add and place them wherever you want them to be organized in your deployment
In the Solution Explorer, select the added assemblies and in the Properties window set the Build Action to "Content", this should be all you have to do, but others have had to also set the "Copy to Output Directory" to "Copy Always", I don't do that
Run a Release Build
Go to the Properties view for your deployment Project
Go to the Publish Tab and Click on the Application Files button
Your files should all be available and added to the Deployment
Set up your ClickOnce settings however you need them to be
Publish your ClickOnce package
Your published package should contain all of the assemblies you need now.
Keep your separate Deployment workspace set up this way and never check it in. Do your work in your development workspace. Whenever a new deployment is needed, open your solution in your Deployment workspace and get the latest code, build, then publish.