I'm trying to get one of our projects building on Visual Studio Team Services.
The issue is with candle.exe, specifying "MsBuild x86" the build gets as far as the call to candle.exe then it hangs (it gets there within minutes, then will hang until VSTS terminates the build amlost an hour later).
If I run it with "MsBuild x64" it runs as far as the first time, but fails because it can't find candle.exe
d:\a\1\s\Ref\Ext\WiX.3.5\Lib\wix2010.targets(1813,5): error MSB6003:
The specified task executable could not be run. The system cannot find
the file specified [d:\a\1\s\Configuration\install\Installer.wixproj]
While it complains about the wixproj, that file exists, and I'm fairly sure it's the candle.exe it can't find.
I'm not sure where to go from here.
Things I ended up doing to fix this.
Remove my locally installed version of wix (it was clouding the
issue)
Upgraded the version of wix that gets checkout with the repository on VSTS (yes we should be using NuGet I know).
Explicitly set a value $(WixToolPath)
Explicitly set the ToolPath to $(WixToolPath) when building the wixproj
Switch off ICE validation scripts for the build
The installers now run.
Related
I have the following as part of a "Deploy" project which I run manually from a batch file using msbuild.exe (VS2017).
<Target Name="ZipRelease"
DependsOnTargets="getversion;gettime">
<MakeDir Directories="$(ReleaseDir)" Condition="!Exists('$(ReleaseDir)')" />
<ZipDirectory Condition="Exists('$(BuildDir)')"
SourceDirectory="$(BuildDir)"
DestinationFile="$(ReleaseDir)\$(MODNAME)-$(DLLVersion)_$(CurrentDate).zip" />
</Target>
On one PC I use the Community Edition of VS2017. I may also have installed VS2019 on that machine (no way to check for a couple of weeks). Crucially the batch file forces the use of VS2017. On another PC I have VS2017 Professional.
On the PC using the Community Edition, this task creates correct zip files which use forward-slashes as the path separator. On the PC using VS2017Pro, the task creates zip files with back-slashes which is obviously against the spec and causes lots of problems (the resulting ZIP is deployed on Linux as well as Windows).
This thread indicates DotNet 4.6.1 or later fixes the path separator used when creating ZIP files. I specify ToolsVersion="15.8" as part of the Project configuration (minimum version for the ZipDirectory task), but how do I force the DotNet version for an MSBuild Task?
I've tried uninstalling all earlier versions of Dotnet SDK/target framework from the PC to no avail.
There's also an override documented (Switch.System.IO.Compression.ZipFile.UseBackslash), but that only applies to applications, not MSBuild Tasks.
As seems usual with MS stuff, there's inconsistencies everywhere and my Google skills are insufficient to find an answer so grateful for anybody being able to point me in the right direction.
Installing VS2019 fixes it.
It seems my script automatically configures itself to use the newest version of Visual Studio instead of forcing itself to VS2017 as I had originally stated.
Even though all DotNet version numbers as reported by the build script for its runtime framework are still the same, something is obviously different between running in a VS2017 vs VS2019 environment.
It would be very very nice to figure out exactly what and whether it's possible to force the VS2017 intall to use that as well..
Try to use
<ZipDirectory Condition="Exists('$(BuildDir)')"
SourceDirectory="$(BuildDir)"
DestinationFile="$([System.String]::Copy($(ReleaseDir)\$(MODNAME)-$(DLLVersion)_$(CurrentDate).zip).Replace('\', '/'))" />
Actually, all my agents are using back-slashes for path. And windows always uses back-slashes for path, so I wonder if you have made some changes to your windows or VS IDE to use forward-slashes for that PC.
Linux uses forward-slashes but Windows do not use that by default.
You can open the folder of the C disk to check whether the path uses forward-slashes. And make sure whether you have run some cmd commands to use that.
Open VS IDE, compare with the two versions from the two PCs, open Extensions-->Manage Extensions-->Installed to check whether you have installed some extensions to cause that.
We have a number of .NET Framework projects with a "nuget pack MyProject.csproj" command in the post-build step. We have been using VS2010 (:O I know) until now, and it has been happily spitting out nupkg files.
We recently updated our build tools to the 2019 version (running the new version of varsall.bat before calling msbuild), and the "nuget pack" command now fails:
Error NU5012: Unable to find 'MyProject.dll'. Make sure the project has been built.
What I've tried:
Adding a "nuget spec" step before packing
Upgrading the nuget CLI executable to the latest version
Updating from packages.config to PackageReferences
This allows you to use MSBuild -t:pack. However, two issues:
When running this in the post-build step on my machine, it starts dozens of cmd & MSBuild processes and pegs my CPU.
Our developers are stuck on VS2017 for now, but the 2017 build tools are no longer available for our build server (so we use 2019). The 2017 & 2019 installs put MSBuild in different locations. We could set path variables for all the machines, but that seems brittle.
I'm playing with upgrading one of the projects to the new csproj format, but it is rather involved. Upgrading all of our projects will be an effort all its own, and I'm still exploring the ramifications.
Is there something simple I'm missing which will allow this to work without large modifications?
Error NU5012: Unable to find 'MyProject.dll'. Make sure the project
has been built.
This message indicates that the nuget.exe can't find the output assembly. So you must make sure the assembly is created successfully.
And one point you need to take care, normally we use command like nuget pack foo.csproj -Properties Configuration=Release to pack the assembly built in release mode. If you use command like nuget pack xx.csproj in post-build-event, no matter which configuration you use msbuild to build the project, nuget will always try to find the assembly in ProjectDir/bin/debug.
So when you deploy the project to remote server without bin and obj folders, if you try to use command like msbuild xx.csproj /p:Configuration=Release, the build is in release mode while nuget.exe will search the bin\debug instead of expected bin\release. You should check if you're in same situation.
Why does NuGet pack break with VS2019 build tools?
This issue is not about the build tools package. Since the error message you got came from nuget. Msbuild just help call the nuget.exe, and the cause of the issue is nuget.exe can't find the needed assembly by one specific path. Please check if the path in the error message is right, and then check if the assembly is in that path.
I also ran into the same issue during our TFS upgrade to Azure Devops. The new Nuget task doesn't have the switch for -Build. The fields in the Nuget task screen for Pack also doesn't allow you to add this switch, that's why it's complaining about not finding the dll or the output of the build. I modified the nugetpack.js file on the agent's task folder to test the theory and now the pack options build successfully.
This is the line I added to the js file (towards the bottom of the page):
nugetTool.arg("-Build");
what would be nice is to have this option represented as check box to cover if there is use case to call Nuget pack without -Build switch
I've got a .msi file produced by WiX which is working great, and now I want to wrap it in a bootstrapper. Previously I used setupbld, but as that is now deprecated I'm experimenting for the first time with burn from WiX 3.8.
However, every time I run burn from the command line nothing happens, regardless of parameters. I connected a debugger and got the following output if I run burn.exe with no parameters:
The program '[0x1380] burn.exe: Native' has exited with code -2147024883 (0x8007000d).
Does anybody know what is wrong here?
Note, I am literally running "C:\Program Files (x86)\WiX Toolset v3.8\bin\x86\burn.exe". I notice that burn.exe has an icon resembling an msi package (despite being an exe) so I'm not sure whether this is the installer for burn, or whether it is burn itself.
Tbh, I'm finding that although there is lots of documentation on writing the XML files needed by burn, there seems to be precious little on actually invoking it, and what to expect when one does.
Burn is the bootstrapper engine, not the builder. The error is ERROR_INVALID_DATA, which makes sense because burn.exe does have any data attached to it; The builder copies and modifies it to contain and/or point to containers for your bootstrapper's data.
To build a bootstrapper, you create a WiX document with a bundle element and then run candle.exe and light.exe on it.
Many people use a build system to run their tools and an IDE to manage their projects. WiX integrates with MSBuild and Visual Studio (non-free editions). There is a WiX Bootstrapper project template for Visual Studio provided, too. The SharpDevelop IDE has its own WiX templates (but currently not for the Bootstrapper.)
Note: All WiX projects are MSBuild projects so you can hand-write projects and/or build them with MSBuild instead of the IDE.
I have an WCF project that if i use the Visual Studio option "Publish" gets published fine.
But if I use the MSBuild parameter DeployOnBuild it does not get published correctly. I'm getting an "Could not load type" error, and all of de dlls are there.
I using the MSBuild in a Build Definition in order to have a Continuous Integration Build.
The build parameters I'm using are:
/p:DeployOnBuild=true
/p:DeployTarget=MSDeployPublish
/p:MSDeployPublishMethod=RemoteAgent
/p:MsDeployServiceUrl=http://host/msdeployagentservice
/p:username=#####
/p:password=****
My main problem with this scenario is that the build targets are the same, and the build definition actualy publishes the files, but somehow they are not the same.
Any insights ???
I dont like to answer my on question, but since it may help someone else is the cause of the problem.
One of the projects had a post-build command to copy the resulting
dll to another project specific directory (its not a reference
because it using dependency injection in runtime).
The dlls did not get checked in to TFS because they are not checkout automaticaly
The
Continuous Integration Build fetches the sources from TFS and the dlls are out of sync
The solution was to checkout the dlls before the build so that the checkin updates them
We have a large project at work, under source control, including an MSBuild file to run the build. Recently, the build has stopped working on my machine (I get errors saying that 'zzz' is ambiguous in the namespace 'yyy'). The same MSBuild file is working fine on both the build server and my co-workers machines.
I have tried cloning a new copy of the project from the shared repository, but even with a clean copy, the build is failing for me. I think it must be a problem with the MSBuild settings on my machine, but I haven't been able to find anything that tells me where they are. Any help would be appreciated, since I'm starting to think my machine has just gone crazy.
So, after a lot of hair pulling, I found both the solution to my problem, and the answer to my question.
MSBuild stores it's default options in a set of .rsp files and the .targets files found in the base directory of MSBuild. In my case, this was C:\Windows\Microsoft .NET\Framework\v3.5. The trick is that the options are stored separately for the 32-bit version of MSBuild and the 64-bit version (C:\Windows\Microsoft .NET\Framework64\v3.5. Our build required modifying the default visual basic targets file, which took care of the ambiguous reference call I was getting.
My problem happened because something modified my system path to point to Framework64 instead of Framework. Since my custom .targets file was only applied to the 32-bit version of MSBuild, the ambiguous reference wasn't being resolved correctly. Unfortunately, there isn't a visual difference between running the 64-bit version of MSBuild and running the 32-bit version of MSBuild. When I corrected my system path, everything started working again.