Msbuild copy command failed if path contains double byte characters - msbuild

I am using WIX project to create an MSI file.
Following statements are added in WIXPROJ file to copy MSI file.
copy /y "!(TargetPath)" "$(MSIPath)\"
$(MSIPath) contains the path which is double byte characters.
Ex: F:\Temp\つも追加さ\
error MSB3073: The command "copy /y "E:\BuildMSI\bin\Debug\en-Us\xxx.msi" "F:\Temp\つも追加さ\"" exited with code 1.
Note: Same is working fine Japanese OS. This issue occurs in English OS.
Please help me how to resolve this issue.
Thanks in advance.
Regards,
Dileep

I have used the 'AfterBuild' command instead of 'PostBuildEvent'.
<Target Name="AfterBuild">
<Copy SourceFiles="$(TargetPath)" DestinationFolder="$(MSIPath)" />
</Target>
Issue was solved using the above statements in Wixproject file.

Related

WiX Heat: Pre-build event fires too early on build server

I'm harvesting a directory for my Visual Studio solution.
It works on my local system so far probably because the project build order is being respected.
When I run the installer on a build server it finds the right directory but it has not been created at the time of building the setup file. It throws a HEAT5052 error saying The directory 'a:\b\c' could not be found.
Is there any way to "wait" until or to execute the heat command after all project references are built?
OK so I've spent hours to figure out how to fire Heat AFTER all references are resloved. I only found solutions for the <PreBuildEvent> and <PostBuildEvent> using the Heat command line and the BeforeBuild and AfterBuild targets.
So I found all kind of targets inside the wix2010.targets file located in my
Program files (x86)\MSBuild\Microsoft\Wix\ folder. It contains a target called AfterResolveReferences and it does exactly that. So here's my code I ended up with (in case someone is interested):
<Target Name="AfterResolveReferences">
<HeatDirectory
ToolPath="$(WixToolPath)"
OutputFile="Product.Binaries.wxs"
SuppressFragments="$(HarvestDirectorySuppressFragments)"
Transforms="Filter.xslt"
Directory="$(HarvestFolder)"
DirectoryRefId="MY_FOLDER"
ComponentGroupName="Binaries"
GenerateGuidsNow="true"
SuppressRootDirectory="true"
SuppressRegistry="true"
PreprocessorVariable="var.App.TargetDir">
</HeatDirectory>
</Target>
I had the same problem and it was solved by combining the accepted answer and this answer to ensure that my post build event, which was copying files, always runs:
<RunPostBuildEvent>Always</RunPostBuildEvent>
<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
Also, my build server was using the MSBuild command line, and I used this answer to locate my local MSBuild.exe so I could test my changes locally without having to push to the build server.

Running Paraffin when building a wixproj

I've got a WiX project which pulls in a WiX Fragment with a load of supporting files.
I'm using Paraffin to build the wsx file for the fragment. At the moment I manually run a one line batch file to run with paraffin with the appropriate arguments whenever I make a change the supporting files folder.
Instead I would like paraffin to run as part of the build process. I'm guessing I need to add something to inside the .wixproj file, but I'm not actually sure what.
How do I do this?
Found a solution:
<Target Name="BeforeBuild">
<Exec Command="paraffin -dir SourceDir -groupname MyGroupId -dirref MyDirId output.wxs"/>
</Target>

Weird behavior with $(SolutionDir) with msbuild in a .csproj file being wrong

I have a .sln solution file that references a .csproj project file that has an after build task of something like:
<PropertyGroup>
<PostBuildEvent>
xcopy $(SolutionDir)\dir1\Somefle.xml $(ProjectDir) /Y /I
</PostBuildEvent>
</PropertyGroup>
The solution is built using msbuild with a task like the following:
<Target Name="CompileSolution">
<MSBuild Projects="#(SolutionToBuild)" Targets="Rebuild" Properties="Platform=Any CPU" />
</Target>
Now here's the strange part:
If I:
run the build script (say c:\MyWorkingCopy)
rename the working copy folder (say to c:\YourWorkingCopy)
run the build script again
On step 3, the xcopy will fail, because it will because it will be trying to copy the file from "c:\MyWorkingCopy" - which of course is not where the solution file now resides.
Why does msbuild use the old Solution directory? And is there some way to reset it?
(I am using .NET Framework 3.5)
It may be related to the sln.cache file that is created by msbuild when you build a sln file (it's a temporary proj file built from the sln one), if it is present or if the sln is not modified the sln.cache file may be used... I don't really know but it I think it could help.

SolutionDir set to *Undefined* in post-build xcopy event

I have a project that has a post-build event that xcopies a DLLs to a certain directory:
xcopy "$(TargetDir)$(TargetName).dll" "$(SolutionDir)..\UdpLocationService\bin\Plugins\" /d /y
xcopy "$(TargetDir)$(TargetName).pdb" "$(SolutionDir)..\UdpLocationService\bin\Plugins\" /d /y
However, I have CruiseControl.NET set up as a build server and MSBuild is failing on building that project due to this xcopy post-build event:
MSB3073: The command "xcopy "C:\Build\Services\Windows\VehicleServer\Plugins\Payload\bin\Debug\Payload.dll" "*Undefined*..\UdpLocationService\bin\Plugins\" /d /y xcopy "C:\Build\Services\Windows\VehicleServer\Plugins\Payload\bin\Debug\Payload.pdb" "*Undefined*..\UdpLocationService\bin\Plugins\" /d /y" exited with code 4. in Microsoft.Common.targets(3397, 13)
Any suggestions to get this fixed?
I just ran into the same problem with TeamCity.
The issue here is the $(SolutionDir) property in your build file. You haven't defined it in your call to MsBuild (this is why you see the word undefined in your output).
Call msbuild with the property set, like this:
msbuild myproject.csproj /property:SolutionDir="solution directory"\
Where "solution directory" is the directory containing your solution file. Note the trailing slash, you'll need that to make sure the path is correctly formed.
I fixed this for problems with the Microsoft.SqlServer.Compact nuget package (which adds a similar post-build script), by adding:
<SolutionDir Condition="'$(SolutionDir)'=='' or '$(SolutionDir)'=='*Undefined*'">..\</SolutionDir>
right above the <PostBuildEvent>. You'll want to adjust the relative path to match your project layout.
Follow these steps:
Unload your project file (e.g. *.csproj)
Open your project file for editing
Find the AfterBuild target
Separate out the two invocations of XCopy into two distinct Exec tasks
Save your changes and Reload your project file

How to resolve "Only one project can be specified" error from <msbuild> task in CruiseControl.NET

I'm trying to use the task in CruiseControl.NET version 1.3.0.2918 with a rather straight forward :
<project name="AppBuilder 1.0 (Debug)">
<workingDirectory>c:\depot\AppBuilder\1.0\</workingDirectory>
<triggers/>
<tasks>
<msbuild/>
</tasks>
</project>
However, when the project is run it fails with this information in the build log:
MSBUILD : error MSB1008: Only one
project can be specified. Switch: 1.0
For switch syntax, type "MSBuild
/help"
When I look at the ccnet.log file I find this:
Starting process [C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe] in working
directory [c:\depot\AppBuilder\1.0] with arguments [/nologo "/p:CCNetArtifactDirectory=C:\Program Files\CruiseControl.NET\server\AppBuilder 1.0 (Debug)\Artifacts;CCNetBuildCondition=ForceBuild;CCNetBuildDate=2009-01-22;CCNetBuildTime=09:25:55;CCNetIntegrationStatus=Unknown;CCNetLabel=3;
CCNetLastIntegrationStatus=Failure;CCNetNumericLabel=3;CCNetProject=AppBuilder 1.0 (Debug);CCNetProjectUrl=http://CISERVER01/ccnet;CCNetRequestSource=jstong;
CCNetWorkingDirectory=c:\depot\AppBuilder\1.0\" "/l:ThoughtWorks.CruiseControl.MsBuild.XmlLogger,ThoughtWorks.CruiseControl.MsBuild.dll;C:\Program Files\CruiseControl.NET\server\AppBuilder 1.0 (Debug)\Artifacts\msbuild-results.xml"]
from which I infer that msbuild was run in the correct working directory and that the command line passed to it was:
/nologo "/p:CCNetArtifactDirectory=C:\Program Files\CruiseControl.NET\server\AppBuilder 1.0 (Debug)\Artifacts;CCNetBuildCondition=ForceBuild;CCNetBuildDate=2009-01-22;CCNetBuildTime=09:25:55;CCNetIntegrationStatus=Unknown;CCNetLabel=3;
CCNetLastIntegrationStatus=Failure;CCNetNumericLabel=3;CCNetProject=AppBuilder 1.0 (Debug);CCNetProjectUrl=http://CISERVER01/ccnet;CCNetRequestSource=jstong;
CCNetWorkingDirectory=c:\depot\AppBuilder\1.0\" "/l:ThoughtWorks.CruiseControl.MsBuild.XmlLogger,ThoughtWorks.CruiseControl.MsBuild.dll;C:\Program Files\CruiseControl.NET\server\AppBuilder 1.0 (Debug)\Artifacts\msbuild-results.xml"
If I run this manually at the command line I get a similiar error.
It appears to me that the isn't passing the correct command line to the MSBuild executable.
Can you spot my error? Or is this version of CruiseControl.NET (1.3.0.2918) broken with respect to the task?
I think maybe it is your space in the artifact directory path. MSBuild really does not like spaces as it considers it a break between arguments. Can you try an remove the space from that path and see what happens?
Why is your msbuild tag empty? It should be something similar to:
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>
<workingDirectory>C:\dev\ccnet</workingDirectory>
<projectFile>CCNet.sln</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs>
<targets>Build;Test</targets>
<timeout>900</timeout>
<logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
Without more detail since you don't appear to be specifying a project/solution file which leaves MSBuild assuming one. If you have more than one file that MSBuild is able to use as a project file in that directory that might be causing your issue.DO you have an MSbuild .proj and a .sln file by any chance? Or two solution files?
I had a similar problem and (what Alex said) removing my space did fix the problem. I did however run into another situation where removing the space from a name was not possible. In this case, adding quotes around the name fixed the problem for me.