So, I created a publish profile for my web app. I did this with the GUI in VS 2017 Enterprise. I then found an example of how to change the pubxml to make it zip all the output files. Eventually I ended up with this:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<PublishProvider>FileSystem</PublishProvider>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<PrecompileBeforePublish>True</PrecompileBeforePublish>
<EnableUpdateable>True</EnableUpdateable>
<DebugSymbols>False</DebugSymbols>
<WDPMergeOption>DonotMerge</WDPMergeOption>
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>bin\Release\Publish</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
<Configuration>Release</Configuration>
</PropertyGroup>
<Target Name="ZipPublishOutput" AfterTargets="GatherAllFilesToPublish">
<Exec Command='powershell -nologo -noprofile -command "compress-archive -force -path $(WPPAllFilesInSingleFolder)\* -destinationpath $(publishUrl).zip"' />
</Target>
</Project>
This works perfectly fine if I do a publish through Visual Studio. However, I've been trying everything I can think of to get this to work in MSBuild, with no luck.
Here is an example of what I think should work:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\MSBuild.exe" WebApp.csproj /nologo /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=ReleasePublish
And for reference, here is the version of MSBuild:
Microsoft (R) Build Engine version 15.9.20+g88f5fadfbe for .NET Framework
I know MSBuild is finding the profile pubxml because I can make a change to the settings, such as publishUrl, and those changes are applied the next time I run MSBuild. What doesn't seem to work is the ZipPublishOutput target. And even running MSBuild with diagnostic verbosity shows that GatherAllFilesToPublish never runs, which would mean my target wouldn't run.
I've found many different suggestions and nothing seems to help. A lot of the solutions I found seemed to be with MSBuild not finding the pubxml, but that's not the case here.
So, is GatherAllFilesToPublish something that is Visual Studio specific, and therefore MSBuild doesn't know about it? That seems like how it's acting.
Just got the same problem using msbuild with Jenkins.
To execute the target GatherAllFilesToPublish with msbuild I had to add the target /t:GatherAllFilesToPublish in the msbuild command line.
You should have something like this :
/p:DeployOnBuild=true /p:PublishProfile=fullPathToMyPubXML.pubxml
/t:GatherAllFilesToPublish
Related
I have a simple "Hello World" mvc web application that I am attempting to build in VSTS. My steps are:
Get Sources
Run msbuild on a single project
Publish artifact (publish directory)
Everything works fine whenever I use a profile for msbuild, but I would like to just pass the parameter commands in instead. When I do this I get the following error:
Error : Copying file bin\WebApp01.dll to obj\Release\Package\PackageTmp\bin\WebApp01.dll failed. Could not find file 'bin\WebApp01.dll'.
What mistake am I making with my msbuild parameters? How do I properly duplicate a simple file system profile?
Parameters (error'ing):
/p:DeployOnBuild=true /p:Configuration="Release" /p:Platform="Any CPU" /t:WebPublish /p:WebPublishMethod=FileSystem /p:publishUrl=PublishToOctopus
Profile (works):
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>PublishToOctopus</publishUrl>
<DeleteExistingFiles>False</DeleteExistingFiles>
</PropertyGroup>
</Project>
When using /p:DeployOnBuild=true, you can use the normal Build target. You directly called WebPublish (/t:WebPublish) which expects a build to already have happened but since it doesn't, the file is missing from the expected location.
I have following *.wpp.target file:
<PropertyGroup>
<CopyAllFilesToSingleFolderForMsdeployDependsOn>
ExcludeCustomFilesOrFolders;
$(CopyAllFilesToSingleFolderForPackageDependsOn);
</CopyAllFilesToSingleFolderForMsdeployDependsOn>
</PropertyGroup>
<Target Name="ExcludeCustomFilesOrFolders" BeforeTargets="ExcludeFilesFromPackage">
<ItemGroup>
<ExcludeFromPackageFolders Include="$(MSBuildProjectDirectory)\Media" />
</ItemGroup>
<Message Text="Custom Exclude From %0D Folders: #(ExcludeFromPackageFolders)%0D Files: #(ExcludeFromPackageFiles)" Importance="high"/>
</Target>
If I run it for the first time out of visual studio 17 Media folder is ignored and not published.
After when I comment the line with ExcludeFromPackageFolders node and publish again Media folder is still ignored. It seems that visual studio or msbuild does not refresh changes made inside *.wpp.target file. Do I miss here something or is VS or MSbuild just buggy?
Can you try to add /PROFILE to the linker option? Might fix the problem: https://developercommunity.visualstudio.com/content/problem/136703/wpp-trace-missing-from-pdb-files-in-vs-2017.html
You have to restart visual studio and reload solution everytime you change it. VS caches it.
I have TeamCity build configuration with MSBuild step, when i would like to compile my project with publish profile. My publish profile is located in MyProject\Properties\PublishProfiles\profile.pubxml.
My profile.pubxml:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<PrecompileBeforePublish>True</PrecompileBeforePublish>
<EnableUpdateable>True</EnableUpdateable>
<DebugSymbols>False</DebugSymbols>
<WDPMergeOption>MergeAllOutputsToASingleAssembly</WDPMergeOption>
<UseMerge>True</UseMerge>
<SingleAssemblyName>project</SingleAssemblyName>
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>C:\DevelopmentFolder</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
</PropertyGroup>
</Project>
My build step:
Runner type: MSBuild
Build file path: MyProject.csproj
MSBuild version: Microsoft Build Tools 2013
MSBuild ToolsVersion: 12
Run platform: x86
Now i would like to compile my project with account of parameters from my publish profile. I try to create all parameters as system parameters of build configuration (as in TeamCity says to use "Build Parameters" instead of "/property:" in an MSBuild step. What does that mean?), but i think MSBuild does not take into account parameters, because i can't see in bin directory project.dll file.
Add TeamCity property system.PublishProfile and the value should be your pubxml profile name ("profile" in your example). Then add a build step which runs MSBuild with the target "WebPublish" - it works for me.
I'm trying to make a batch file to publish the few ClickOnce application we have in one click. I'm using msbuild for that, and as an example the below command line shows how I'm doing it:
msbuild
MyApp.sln
/t:Publish
/p:Configuration=Release
/p:PublishUrl="C:\Apps\"
/v:normal > Log.txt
(wrapped for easier reading)
when I run the above command it builds and publish the application in the release directory, i.e. bin\release! Any idea why msbuild doesn't respect PublishUrl property in my example above?
PS: I tried also different combinations including remove 'Configuration', use 'Rebuild' and 'PublishOnly' as targets, and remove the the quotation marks but without any success.
You are setting the wrong property. Try PublishDir instead.
You can pass it into MSBuild as you are or you can set it in the project file (or maybe the sln file too, not sure I always use the project file.) like this
<PropertyGroup>
<PublishDir>C:\Dev\Release\$(BuildEnvironment)\</PublishDir>
</PropertyGroup>
I've just done a few blog posts on MsBuild and ClickOnce stuff, check it out you 'should' find them useful...
Some features are done by Visual-Studio and not by the MSBuild-script. So the click-once-deployment behaves differently when it's executed from the command-line.
The ApplicationRevision isn't increased with every build. This works only when is exectued from Visual Studio
In in somecases, the PublishUrl isn't used. Quote from MSDN:
For example, you could set the PublishURL to an FTP path and set the InstallURL to a Web URL. In this case, the PublishURL is only used in the IDE to transfer the files, but not used in the command-line builds. Finally, you can use UpdateUrl if you want to publish a ClickOnce application that updates itself from a separate location from which it is installed.
I've created a special MSBuild-file which does this things. It runs the publish-target and copies then the files to the right location.
An example of the build-file, as requested by alhambraeidos. It basically runs the regular VisualStudio-build and then copies the click-once data to the real release folder. Note that removed some project-specific stuff, so it's maybe broken. Furthermore it doesn't increase the build-number. Thats done by our Continues-Build-Server:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Publish" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<!-- the folder of the project to build -->
<ProjLocation>..\YourProjectFolder</ProjLocation>
<ProjLocationReleaseDir>$(ProjLocation)\bin\Release</ProjLocationReleaseDir>
<ProjPublishLocation>$(ProjLocationReleaseDir)\app.publish</ProjPublishLocation>
<!-- This is the web-folder, which provides the artefacts for click-once. After this
build the project is actually deployed on the server -->
<DeploymentFolder>D:\server\releases\</DeploymentFolder>
</PropertyGroup>
<Target Name="Publish" DependsOnTargets="Clean">
<Message Text="Publish-Build started for build no $(ApplicationRevision)" />
<MSBuild Projects="$(ProjLocation)/YourProject.csproj" Properties="Configuration=Release" Targets="Publish"/>
<ItemGroup>
<SchoolPlannerSetupFiles Include="$(ProjPublishLocation)\*.*"/>
<SchoolPlannerUpdateFiles Include="$(ProjPublishLocation)\Application Files\**\*.*"/>
</ItemGroup>
<Copy
SourceFiles="#(SchoolPlannerSetupFiles)"
DestinationFolder="$(DeploymentFolder)\"
/>
<Copy
SourceFiles="#(SchoolPlannerUpdateFiles)"
DestinationFolder="$(DeploymentFolder)\Application Files\%(RecursiveDir)"
/>
<CallTarget Targets="RestoreLog"/>
</Target>
<Target Name="Clean">
<Message Text="Clean project:" />
<MSBuild Projects="$(ProjLocation)/YourProject.csproj" Properties="Configuration=Release" Targets="Clean"/>
</Target>
</Project>
I'll put in my 2 cents, this syntax seems to work (right or wrong):
/p:publishUrl="C:\\_\\Projects\\Samples\\artifacts\\Web\\"
For me, the soultion was to escape the path.
Instead of:
/p:PublishUrl="C:\Apps\"
Put:
/p:PublishUrl="C:\\Apps\\"
I have three Visual Studio solutions. The first is configured to build as Release, and the other two are set to build as Debug.
When running a simple MSBuild script explicitly stating the configuration to build (Debug), the first project is still built as Release.
Sample script:
<Target Name="Build">
<ItemGroup>
<ProjectToBuild Include="$(SolutionsPath)\Solution1.sln"/>
<ProjectToBuild Include="$(SolutionsPath)\Core\Solution2.sln"/>
<ProjectToBuild Include="$(SolutionsPath)\UI\Solution3.sln"/>
</ItemGroup>
<MSBuild Projects="#(ProjectToBuild)"
Targets="Rebuild"
Properties="Configuration=Debug;Platform=Any CPU"/>
</Target>
I have tried variations of the above such as the following, but I always end up with the same result.
<Target Name="Build">
<ItemGroup>
<ProjectToBuild Include="$(SolutionsPath)\Solution1.sln">
<Properties>Configuration=Debug</Properties>
</ProjectToBuild>
<ProjectToBuild Include="$(SolutionsPath)\Core\Solution2.sln">
<Properties>Configuration=Debug</Properties>
</ProjectToBuild>
<ProjectToBuild Include="$(SolutionsPath)\UI\Solution3.sln">
<Properties>Configuration=Debug</Properties>
</ProjectToBuild>
</ItemGroup>
<MSBuild Projects="#(ProjectToBuild)"
Targets="Rebuild"
Properties="Platform=Any CPU"/>
</Target>
I note there is a similar question, MSBuild task - Build fails because one solution being built in release instead of debug, but that is specific to TFS and Teambuild. I am talking pure MSBuild with a simple project file created from scratch.
How can I fix this problem?
Regarding the question of spelling of platform any cpu, it turns out there is an issue, already reported elsewhere here on StackOverflow and Microsoft. It affects MSBuild in general and the entire issue of Platform documentation is omitted in my dotnet v3.5 MSBuild /help. So perhaps this will help someone!
Links
"AnyCPU" vs "Any CPU" in TFS 2010
MSBuild inconsistent platform for "Any CPU" between solution and project
Closed as Won't Fix
Type: Bug
ID: 503935
Opened: 10/26/2009 1:29:12 PM
Access Restriction: Public
0 Workaround(s)
5 User(s) can reproduce this bug
The MSBuild Platform property has a different value for Any CPU depending upon whether you are building a solution or building a project.
- for Solution - use Platform="Any CPU" - with space
- for Project - use Platform="AnyCPU" - without space
OK I have found the issue. Nothing related to MSBuild, but instead the solution being built. Posting to save someone else the heartache.
For whatever reason the Debug configuration was configured within the solution like so:
alt text http://www.freeimagehosting.net/uploads/cad0bdf1c0.jpg
So MSBuild was only doing what it was told too...
I was getting this same error. The solution was to explicitly specify the target platform with:
msbuild.exe /p:Platform="Any CPU"
This only started happening since I upgraded to windows 7, so I guess it is something to do with that.
Have you tried running with /v:diag?
Also, aside: I think you want "AnyCPU" (no space).