I recently started working with TFS 2015 (Update 4). And I'm trying to configure and build to do the folowing:
Restore nuget packets
Build whole solution
Publish (move to specific uri)
My solution has the folowing structure:
Solution
DALs (EF6 code first model)
WPF App 1
ASP.NET Website 1
WPF App 2
ASP.NET Website 2
Note: Both Websites have publish profiles named "Publish", and both are same except the publishUrl inside of them.
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<PublishProvider>FileSystem</PublishProvider>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>..\Deploy\AppServerHost</publishUrl>
<DeleteExistingFiles>False</DeleteExistingFiles>
</PropertyGroup>
What have I tried on TFS...
And the publish:
What I'm trying to acomplish, is that when I start the build, it should build the whole solution, copy the release of WPF regulary, and most important, not just build the websites, it should also publish them. Because now I only get their bins.
To build the whole solution, you need to make sure you have mapped all your projects/the whole solution folder in Repository tab, and specify the solution or use **\*.sln (you have already done this according to your screenshot) in Visual Studio Build task:
You only get bins because you only specify **\binin Contents of Copy and Publish Build Artifacts task. Since you are using TFS 2015.4, we recommend that you do not use Copy and Publish Build Artifacts task, it's deprecated. Instead, you should use the Copy Files and Publish Build Artifacts tasks.
In Copy Files task, specify match pattern filters (one on each line) that you want to apply to the list of files to be copied.
In Publish Build Artifacts task, specify the path to the folder or file you want to publish. You could refer to the links for more details.
I have a folder on my web application which is used to store user uploads, i.e. profile pictures, that sort of thing.
When I use WebDeploy, there is an option for "Leave extra files (Do not delete)" which when ticked makes sure that the profile pictures are not deleted.
What I am seeking is a way to ensure that even if that is unticked, a certain folder is safe from deletion. The reason for this being that I don't want another developer to accidentally disable the feature in future. Or me for that matter.
Any ideas? I have seen a few similar questions on here but nothing seems to be relevant to Visual Studio 2010, which is what I am using.
(I assume you're using publish profiles as per Visual Studio 2010 w/ the Azure SDK or Visual Studio 2012 RTM. If you're not, create an MSBuild file called ProjectName.wpp.targets in the project root and put content in that instead)
You can disable all forms of deletes by setting <SkipExtraFilesOnServer>true</SkipExtraFilesOnServer> in your publish profile (equivalent to the checkbox you mentioned).
To skip a particular directory, a comment on this question implies you can use the following syntax:
<ItemGroup>
<ExcludeFoldersFromDeployment Include="FolderName" />
</ItemGroup>
But I've never seen that before and haven't tested it. Failing that, you can specify an explicit skip rule. "FolderName" is being skipped here - keep in mind that AbsolutePath is a regex:
<MsDeploySkipRules Include="SkipFolderName">
<SkipAction>Delete</SkipAction>
<ObjectName>dirPath</ObjectName>
<AbsolutePath>FolderName$</AbsolutePath>
</MsDeploySkipRules>
NOTE: There are some scenarios in which skip rules don't work when using Visual Studio unless you also set UseMsDeployExe to true
You can set specific rules on the target machines using the msdeploy.exe.configsettings file, there is also a msdeploy.exe.configsettings.example file in the same folder. The file is located in %program files%\IIS\Microsoft Web Deploy - folder see Web Deploy Rules
You can set Rules and skipDirectives here and enable whether they are defaulted so you get your expected default behaviour.
I have a Web Application project in VS 2012 and when I use the web publishing tool it builds successfully but doesn't copy any files to the publish target (File System in this case).
If I look at the build output I can see everything gets copied over to obj\Release\Package\PackageTmp\ correctly but then all I see in the build output is this:
4>Done building project "{Project}.csproj".
4>Deleting existing files...
4>Publishing folder /...
4> ========== Build: 3 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
========== Publish: 1 succeeded, 0 failed, 0 skipped ==========
Even though it says the publish succeeded there are not files in the target directory for the publish.
I have seen this in multiple projects and sometimes it seems like the Solution/Platform configurations cause this problem but I haven't been able to pinpoint an exact cause for this.
Has anyone else seen this happening or have an idea on how to get this working correctly?
UPDATE:
I may have found a workaround for this. I just had this happen again and I was messing around with the publish settings. Once I changed the selected Configuration on the Settings tab away to another configuration and then back to the one I wanted to use all my files started publishing again. Hopefully this works on other projects in the future.
UPDATE 2:
I posted a bug on Microsoft Connect and heard back from a developer on the VS Web Developer team. He said they have fixed this issue in their internal builds and will releasing an update to the publish tool soon that will fix this problem.
UPDATE 3:
This has been recently fixed with Visual Studio 2012 Update 2
Same problem. The workaround was changing the publish settings from Release to Debug. Re-publish and then change back to Release...
This may be caused by solutions/projects that were created with the RC of vs2012. This happened to me months ago and fixed the problem by making sure my solution build configurations matched my project configurations...
I just recently experienced the same problem when opening the same solution originally created in vs2012RC with VS2012 Express for Web. I did exactly what the original poster suggested and it fixed my problem.
Here is the thread that lead me to the answer:
connect.microsoft.com/VisualStudio/feedback/details/746321/publish-web-application-fails
The pertinent response from the conversation above that helped me was:
Posted by Microsoft on 6/13/2012 at 12:00 PM Hi Andrew,
This was a bug in how we handle the solution configuration vs. the
project configuration. We incorrectly assumed that they would be the
same (e.g. Solution's Release|x86 would have each project set to
Release|x86 as well), which caused us to use the wrong build
properties for publishing files.
The workaround is to make the solution configuration and build
configuration match. This issue will be fixed in the next release of
Visual Studio 2012.
Thanks,
- Jimmy Lewis SDET, Visual Web Developer team
To take this a bit further. You have two files that are created when you create a publish profile.
NewProfile.pubxml
NewProfile.pubxml.user
When you open a project that has these files in the PublishProfile folder from a source control it only has the .pubxml file and not the .publxml.user file, so it creates the .publxml.user file on the fly when you open the project.
When it creates the new .publxml.user on the fly the xml looks like:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>
When you create a new profile it creates xml that looks like:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<TimeStampOfAssociatedLegacyPublishXmlFile />
<EncryptedPassword />
</PropertyGroup>
</Project>
If you take the <PropertyGroup> node and put it in the .pubxml.user file your PublishProfiles will start working again.
An easy fix is to delete your publish profile and create a fresh one.
when you right click on your solution and select publish, you have a profile set. delete this and create a new one.
this will fix it.
I had this problem from switching from 2010 to 2012
I had same error and I change the setting from release to debug and the problem resolved..
I had this same problem however none of the answers in this thread worked for me. My issue was that there is a directory that contains dynamically generated (by my app) static HTML files. The entire directory was not being published.
The solution that worked for me was found here:
One issue I got a while back and thought I should document was that certain file types were not being uploaded when I published my project.
The file types in question were .pdf files and .rtf.
The reason this happened was because these file extensions were not recognized as requiring publishing by Visual Studio. Luckily this can be changed in Visual Studio.
Select the file(s) that aren’t being copied. In Properties ensure that Build Action is set to Content.
If this doesn’t work the following can be tried.
Under the Project menu select Package/Publish Web and notice this drop down:
Try changing this to All files in this project folder.
This is because the .pubxml.user contains required information to publish, and that file isn't (and shouldn't) be included in source control. To fix this VS bug, copy the information from the .pubxml.user file to the .pubxml file. The relevant properties are:
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
Put those in your .pubxml and you should be good to go.
I tried all of these solutions but this is the one that works every time.
We just change the "Publish method:" from "File System" to for example "Web Deploy", and immediately change it back to "File System".
I have (had) the same problem for several projects. The only ones hit seem to be web projects. Deleting and recreating the profile solves the problem only once. Additionaly, comparing the publishxml generated yields no differences, so it does not seem related to the profile at all.
The workaround mentioned by OP to change build problems back and forth seems the only reliable solution at this time.
I ran into the same problem on VS 2010, after checking publish output, event logs, turning on and checking visual studio logs etc I then decided to remove the web publish (via add/remove) which I believe had been recently updated to v1.0.30810.0. This resolved the problem.
Here we had the same problem.
We just change the "Publish method:" from "File System" to for example "Web Deploy", and immediately change it back to "File System".
The following worked for me:
Simply change from Release>Debug>Release (or vice-versa) and then publish.
No need for deleting, editing, publishing anything you don't need to.
My problem was in wrong configuration of myproject.csproj file. '_address-step1-stored.cshtml' file did not copy on publish. 'None' changed to 'Content', now it's ok.
Same problem with VS 2012 Pro with a disk publish target. Project used to publish correctly but started doing this issue where it failed to copy the files to the destination folder.
Solution was to edit the publish profile, change the mode from Release (Any CPU) to debug then back to Release (Any CPU). Doing this causes the PublishProfiles\projname.pubxml.user file to be rewritten (as described above). Looks like it added the LastUsedBuild,LastUsedPlatform and TimeStampOfAssociatedLegacyPublishXmlFile elements under the propertygroup node. After the publish is complete, it adds another ItemGroup with individual files and publish times.
For what it's worth, I eventually gave up on fighting with Web Deploy to get it to do what I wanted (copy deployable files and nothing else), so I scripted it in PowerShell and am really happy with the result. It's much faster than anything I tried through MSBuild/Web Publish, presumably because those methods were still doing things I didn't need.
Here's the gist (literally):
function copy-deployable-web-files($proj_path, $deploy_dir) {
# copy files where Build Action = "Content"
$proj_dir = split-path -parent $proj_path
[xml]$xml = get-content $proj_path
$xml.Project.ItemGroup | % { $_.Content } | % { $_.Include } | ? { $_ } | % {
$from = "$proj_dir\$_"
$to = split-path -parent "$deploy_dir\$_"
if (!(test-path $to)) { md $to }
cp $from $to
}
# copy everything in bin
cp "$proj_dir\bin" $deploy_dir -recurse
}
In my case I'm calling this in a CI environment (TeamCity), but it could easily be hooked into a post-build event as well.
This action was successful for me:
Kill Publish Profiles in "Properties>PublishProfiles>xxxx.pubxml" and re-setting again.
I found the I could get around this problem by changing the target location from obj/[release|stage|..] to a new path outside of the solution folders completely eg c:\deployment. It seems like VS 2012 was getting confused and maybe giving up somewhere during the publish process.
Matt
Had the same problem recently in VS 2013 for a MVC project in which I imported Umbraco CMS. I couldn't publish. The answer above helped, though I needed a while to figure out what I actually should do in VS. It needed some research e.g. on MS blogs to find out. I try to say it simple:
Choose in the VS toolbar a certain configuration e.g. Release and Any CPU. Run the project.
Afterwards right-click in the Solution Explorer on the solution in question, choose Publish. Create a new publishing profile or use a given one, but always make sure that in the settings the same configuration (e.g. Release and Any CPU) is chosen, as before you run the project the last time.
Additionally in my case it was necessary to delete the OBJ folder because here the settings from my last unsuccessful tries to publish got stuck, though I restarted VS and deleting all publishing profiles.
I have a Web Application with several other referenced Projects in the Solution. I've deployed successfully with a single Publish configuration many times in the past. I changed the Project Configuration from Debug to Release for a Project that had been missed in the past. The next time I attempted to deploy I got these symptoms, where the Publish just quietly fails - it does nothing and says it succeeded:
1>------ Build started: Project: Project, Configuration: DeployProduction Any CPU ------
1>
2>Publishing folder /...
========== Build: 1 succeeded, 0 failed, 9 up-to-date, 0 skipped ==========
========== Publish: 1 succeeded, 0 failed, 0 skipped ==========
The only way to recover it was to wipe out the Publish profile, close Visual Studio to force it to save the deletion, reopen it, and recreate the Publish profile from scratch. Once I did that I could Publish fine again.
Win8 VS2012, crappy laptop.
In Visual Studio 2012, switching between releases still causes problems.
We added a pre-build event to delete the obj folder: del /s /f /q $(ProjectDir)\obj and it fixed the issue of publishing. Cleaning works sometimes, but not always.
I finally found the answer by myself. All of the above solutions doesnt work for me.
What i had done is that i move the project to drive c change the project folder to something shorter and boom it publish..
the reason that it failed on my side is that i had very long project name/heirarchy.
C:\Users\user\Desktop\Compliance Management System\ComplianceIssueManagementSystem\ComplianceIssueManagementSystem
I had thought of this because sometimes when i extracted rar file it says that the name/path is too long. I thought it will be the same as visual studio 2012 publish. and it does!
hope it will help you guys.
Check your current project that whether you have made back copy with same class name and different page name (Class name will inherit copied file). Ultimately that will confuse the compiler!!!
CodeFile="Consolidated.aspx.vb" Inherits="Consolidated
None of the above solutions worked for me.
But I noticed that of our five ASP.NET MVC projects in our main solution, four of them put the deployment package in the right place, while one left it under obj\Debug.
I compared the projects and found a discrepancy. The solution was to change this:
<Import
Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
to this:
<Import
Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets"
Condition="'$(VSToolsPath)' != ''" />
<Import
Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets"
Condition="false" />
After I made this change, all five projects put their deployment packages in the right spot.
(Sorry about the long lines, but I couldn't find a better way to condense them.)
I encountered this with Visual Studio generated Service Reference files becoming too long in terms of the overall path length.
Shortened them by re-generating the Service Reference using svcutil.exe, deleting all the original Service Reference files.
svcutil can be called like this:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\SvcUtil.exe" /language:CS http://myservice /namespace:*,My.Namespace
My.Namespace should be replaced with the existing namespace in the generated service proxy (typically found in the Reference.cs file) to avoid compilation errors.
http://myservice should be replaced with the service endpoint url.
I've got into same problem. None of the above solutions worked for me.
So, I've excluded the files which failed to copy while publishing.
I had published the website several times. But one day when I modified some aspx file and then tried to publish the website, it resulted in an empty published folder.
On my workaround, I found a solution.
The publishing wizard will reflect any error while publishing but will not copy any file to the destination folder.
To find out the file that generates the error just copy the website folder contents to a new folder and start the visual studio with that website.
Now when you try to publish it will give you the file name that contains errors.
Just rectify the error in the original website folder and try to publish, it will work as it was earlier.
Follow these steps to resolve:
Build > Publish > Profile > New
Create a new profile and configure it with the same settings as your existing profile.
The project will now publish correctly. This often occurs as a result of a source-controlled publish profile from another machine that was created in a newer version of Visual Studio.
FIXED - various solutions offered didn't work for me. What did work for me with VS Community 2017, Windows Server 2012 R2 was to change the TEMP and TMP environmental variables for the user and then restart the system and deploy again (restarting VS was not enough). These temp variables are where VS does the temp publish.
Restarting visual studio after changing temp variables didn't do the trick, had to reboot system.
Try quitting Visual Studio, delete the relevant pubxml.user file in your PublishProfiles directory, restart VS and publish. Worked on VS 2019.
First:
Build in release Configuration.
In Project Properties-> page select All files and folders under
Package/Publish Web.
Rebuild solution (after Clean solution).
now publish.
While publishing recheck what u have opted.
this should do it. It did for me!:)
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How can I use Web.debug.config in the built-in visual studio debugger server?
I want to use the Web.config transformation that works fine for publish also for debugging.
When I publish a web app, Visual Studio automatically transforms the Web.config based on my currenctbuild configuration.
How can I tell Visual Studio to do the same when I start debugging?
On debug start it simply uses the default Web.config without transformation.
Any idea?
OK, with the understanding that web.debug.config & web.release.config are for package/publish only. I have come up with a way in which to enable what you are trying to do. I've blogged about it at https://devblogs.microsoft.com/aspnet/asp-net-web-projects-web-debug-config-web-release-config/.
Here is the summary.
Now let’s see how we can enable what the question asker wants to do.
To recap, when he builds on a particular configuration he wants a specific transform to be applied to web.config. So obviously you do not want to maintain a web.config file, because it is going to be overwritten.
So what we need to do is to create a new file web.template.config, which is just a copy of web.config. Then just delete web.config by using Windows Explorer (don’t delete using Visual Studio because we do not want to delete it from the project).
Note: If you are using a source control provider which is integrated into Visual Studio then you probably want to delete web.config from source control.
Also with this we do not want to use web.debug.config or web.release.config because these already have a well defined role in the Web Publishing Pipeline so we do not want to disturb that. So instead we will create two new files, in the same folder as the project and web.template.config, web.dev.debug.config and web.dev.release.config.
The idea is that these will be the transforms applied when you debug, or run, your application from Visual Studio. Now we need to hook into the build/package/publish process to get this all wired up. With Web Application Projects (WAP) there is an extensibility point that you can create a project file in the same folder with the name {ProjectName}.wpp.targets where {ProjectName} is the name of the project. If this file is on disk in the same folder as the WAP then it will automatically be imported into the project file. So I have created this file. And I have placed the following content:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- Make sure web.config will be there even for package/publish -->
<Target Name="CopyWebTemplateConfig" BeforeTargets="Build">
<Copy SourceFiles="web.template.config"
DestinationFiles="web.config"/>
</Target>
<PropertyGroup>
<PrepareForRunDependsOn>
$(PrepareForRunDependsOn);
UpdateWebConfigBeforeRun;
</PrepareForRunDependsOn>
</PropertyGroup>
<!-- This target will run right before you run your app in Visual Studio -->
<Target Name="UpdateWebConfigBeforeRun">
<Message Text="Configuration: $(Configuration): web.dev.$(Configuration).config"/>
<TransformXml Source="web.template.config"
Transform="web.dev.$(Configuration).config"
Destination="web.config" />
</Target>
<!-- Exclude the config template files from the created package -->
<Target Name="ExcludeCustomConfigTransformFiles" BeforeTargets="ExcludeFilesFromPackage">
<ItemGroup>
<ExcludeFromPackageFiles Include="web.template.config;web.dev.*.config"/>
</ItemGroup>
<Message Text="ExcludeFromPackageFiles: #(ExcludeFromPackageFiles)" Importance="high"/>
</Target>
</Project>
Let me explain this a bit. I have created the CopyWebTemplateConfig target which will always copy web.template.config to web.config on build, even if you are not debugging your application in Visual Studio.
This is needed because we still need to support the package/publish process of Visual Studio. Then I extended the property PrepareForRunDependsOn to include the UpdateWebConfigBeforeRun target. This property is used to identify the list of targets which needs to be executed before any managed project is run from Visual Studio.
In this target I am using the TransformXml task to transform web.template.config, using the correct web.dev.***.config file. After that your app starts up using the correct web.config based on your build configuration.
After that I have another target ExcludeCustomConfigTransformsFiles, which I inject into the package/publish process via the attribute BeforeTargets=”ExcludeFilesFromPackage”. This is needed because we do not want these files to be included when the application is packaged or published.
So that is really all there is to it.
To explain the package/publish process a bit more for this scenario. When you package/publish web.debug.config or web.release.config, depending on build configuration, will still be used. But ultimately the file that it is transforming is web.template.config, so you may have to adjust depending on what you have in that file. Questions/Comments?
Andrew is on the right path. When you are using this feature here is how it was designed to be used.
web.config
This is the config file which developers should use locally. Ideally you should get this to be standardized. For instance you could use localhost for DB strings, and what not. You should strive for this to work on dev machines without changes.
web.debug.config
This is the transform that is applied when you publish your application to the development staging environment. This would make changes to the web.config which are required for the target environment.
web.release.config
This is the transform that is applied when you publish your application to the "production" environment. Obviously you'll have to be careful with passwords depending on your application/team.
The problem with transforming the web.config that you are currently running is that a transform can perform destructive actions to the web.config. For example it may delete a attributes, delete elements, etc.
You could just use the 'default' web.config as your development/debugging version, and then the web.release.config would of course continue to be the release version, since its transforms are applied when you publish.
In your debug configuration, add a post-build step, and use it to replace/transform your web.config
Although I agree that the simplest approach is usually the best, I can easily imagine a circumstance where for some period of time you want to connect your IDE to a test database instead of your development database. Although you can specify the development connect strings in your default web.config file, it would be really nice to have a Web.Test.config file so that when you swap your build configuration to "Test", you would automatically get the new settings while still in your IDE.
The historical alternative is commenting out one set of connection strings for another, but these new config transforms held out the hope of finally putting a stake in the heart of that ugly practice. Although one default file for development and a transform for release may work much of the time, adding a post-build step to transform the web.config file is the more complete answer in my opinion.