I have enabled "Package Restore", into our builds, to which we have a nightly build to ensure everything builds correctly.
We are getting package errors on our build machine, but not on our local machines.
The error is:
nuget.targets (43): Unable to find version (2.5.1) Castle.Core
I would assume the version are package are irrelevant, but I've added for context.
Any thoughts?
Package Config:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Castle.Core" version="2.5.2" />
<package id="FluentNHibernate" version="1.2.0.712" />
<package id="Iesi.Collections" version="3.1.0.4000" />
<package id="NHibernate" version="3.1.0.4000" />
<package id="NHibernate.Castle" version="3.1.0.4000" />
</packages>
Set the build log to output at a diagnostic level. This should show the error during the nuget portion of the build.
The switch is:
/verbosity:diag
You didn't say what you are using to initiate the CI, so I assume you know how to modify the invocation.
You can also try to run the nuget.targets file manually via msbuild from the command line. From the project folder try:
msbuild myproj.csproj /target:RestorePackages /v:diag
or
msbuild myproj.csproj /target:BuildPackages /v:diag
Make sure all the package sources you need for restoring are set and not disabled on the ci machine.
To list/add them :
nuget.exe sources <List|Add|Remove|Enable|Disable|Update> -Name [name] -Source [source]
This could also be a proxy issue, but it's less likely since support has been added in recent nuget.exe and it would ask for credentials.
Related
I have a solution consisting of multiple projects, several of which reference NuGet packages. There's a web site but also a service which has to be built for x86 or x64; the service is what I'm currently trying to build.
We're on TFS 2013; for this particular solution, I'm using Visual Studio 2015.
"Allow NuGet to download missing packages" and "Automatically check for missing packages during Visual Studio build" are both checked.
I was running NuGet 3.4.4, I've updated to 4.6.2.
I can build fine from Visual Studio. But automated builds on the server fail; but more importantly, it also fails if I try to run MSBuild locally. Similar to this question and this one.
As far as I can tell, the release template is the correct version (12), but I don't think it's a server issue, since I can't build locally either.
The packages are not in source control.
I have a nuget.config in the solution root folder; it previously was in a .nuget folder under the solution root. I do not (and never did) have nuget.exe or nuget.targets in the nuget folder. Here's the config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="NuGetCache" value="\\BuildServer\NuGetPackages" />
<add key="NuGetV2" value="https://www.nuget.org/api/v2/" />
</packageSources>
<packageRestore>
<add key="enabled" value="True" />
<add key="automatic" value="True" />
</packageRestore>
<solution>
<add key="disableSourceControlIntegration" value="true"/>
</solution>
</configuration>
If I (manually) clear the packages and run
MSBuild /p:Configuration=Release;Platform=x64
(from a VS2015 command prompt), it fails, because it can't find the referenced packages.
As suggested in this answer, I've removed the EnsureNuGetPackageBuildImports targets from my projects; they did not have a RestorePackages tag or an import for nuget.targets.
I tried adding a pre-build event to do the package restore (yes, I realize this is the "old" way of doing things)
"C:\Program Files (x86)\NuGet\nuget.exe" restore -ConfigFile "$(SolutionDir)nuget.config" -PackagesDirectory "$(SolutionDir)packages"
... but it consistently fails ("The command exited with code 1"). If I copy the NuGet command line from the MSBuild output and execute it on its own, it succeeds.
I have noticed one odd thing: in the pre-build event, NuGet says "The folder d:\path\to\solution\project1\bin\Release-x64 does not contain an msbuild solution or packages.config file to restore". I'm not sure why it's looking for those in the output folder.
I do have a workaround for this. We have a network share set up to use as sort of a package cache. If I hand-edit the project files and change each reference so that the HintPath points to \\BuildServer\NuGetPackages\ rather than ..\packages\, the build will succeed. But this is ugly, and more importantly it significantly degrades the performance of Visual Studio.
I have a web project that I am publishing from the command line, using a publish profile that does a few additional tasks (excludes some files and folders, grunt, publishing another project in turn).
One two machines (A and B), it works fine from right-click > Publish... in Visual Studio, and choosing the correct publish profile.
Historically, on both machines, it has also worked with the following command line:
msbuild MyProject.csproj /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=myProfile /v:n
However now, machine B is not publishing correctly.
The publish profile is configured with <WebPublishMethod>FileSystem</WebPublishMethod at the top, however from the logs, it is attempting a Package publish type instead, for no apparent reason.
Here is the full publish profile:
<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>..\Production</publishUrl>
<DeleteExistingFiles>False</DeleteExistingFiles>
<ExcludeFoldersFromDeployment>Content;Scripts;Pages</ExcludeFoldersFromDeployment>
<ExcludeFilesFromDeployment>index-dev.html;index.html;debug.html;JSLintNet.json;Gruntfile.js;package.json;packages.config;publishall.bat;publishapi.bat</ExcludeFilesFromDeployment>
<BuildDependsOn>
$(BuildDependsOn);
RunGrunt;
PublishApi;
</BuildDependsOn>
</PropertyGroup>
<Target Name="RunGrunt">
<Message Text="Running grunt production..." />
<Exec Command="grunt production" />
</Target>
<Target Name="PublishApi">
<Message Text="Publishing API..." />
<Exec Command="publishapi" />
</Target>
</Project>
As you'd expect, because it is just doing a Package, no files ever appear in the publishUrl directory. Again, the publish profile works fine from VS2013, using right-click publish.
In the log on machine A I get this excerpt:
**ValidatePublishProfileSettings**:
Validating PublishProfile(myProfile) settings.
But in machine B it doesn't appear.
Later in the log on machine A it contains:
**WebFileSystemPublish**:
Creating directory "..\Production".
Copying obj\Release\Package\PackageTmp\cache.manifest to C:\SVN\Trunk\src\Web Sites\MyProject\..\Production\cache.manifest.
Copying obj\Release\Package\PackageTmp\Global.asax to C:\SVN\Trunk\src\Web Sites\MyProject\..\Production\Global.asax.
Copying obj\Release\Package\PackageTmp\Web.config to C:\SVN\Trunk\src\Web Sites\MyProject\..\Production\Web.config.
Copying obj\Release\Package\PackageTmp\bin\MyProject.dll to C:\SVN\Trunk\src\Web Sites\MyProject\..\Production\Blithe.Web.Collect.dll.
but later in the log on machine B, in place of the above, it contains:
**Package**:
Invoking Web Deploy to generate the package with the following settings:
$(LocalIisVersion) is 7
$(DestinationIisVersion) is 7
$(UseIis) is True
$(IisUrl) is <<<some url>>>
$(IncludeIisSettings) is False
$(_DeploymentUseIis) is False
$(DestinationUseIis) is False
The only difference I can think of between the two machines, is that I installed an update on machine B (the problem machine) for 'Windows Azure SDK for .NET (VS2013) - 2.3'. Any ideas how and why this might have broken it?
I tried adding /p:PublishProfileRootFolder="Properties\PublishProfiles" as mentioned here but this didn't work.
Adding:
/p:VisualStudioVersion=12.0
to the command worked.
Machine B had Visual Studio 2008 installed on it as well, whereas Machine A didn't. Setting the version to 12.0, or even 11.0 works. Setting it to 10.0 ignores the publish profile and just does a package install.
Surprisingly it seems to default to 10.0.
This issue did not emerge until the update to Azure SDK 2.3, which DID have some changes to Web Publish, so that may well have led to this issue.
I added Fody ProperyChanged to two projects in my solution. Package Restore is enabled on the solution. However, the TFS Build Service fails building with the following error:
WindowsUI.csproj (443): The imported project
"SolutionDir\Tools\Fody\Fody.targets" was not found. Confirm that the
path in the declaration is correct, and that the file exists
on disk.
The folder is indeed not there. I could check it into source control, obviously. However, should it not be populated by the NuGet Package Restore? Or am I misunderstanding what NuGet Package Restore does?
I ran into a similar problem trying to get a solution to build on Visual Studio Online.
Problem is that packages are restored before a project build, but before that the project
files and target inclusions from packages (still to be restored) have already been interpreted.
Use the before build hook as described here:
http://sedodream.com/2010/10/22/MSBuildExtendingTheSolutionBuild.aspx
In your before.solutionname.sln.targets file put something like this to force all packages to be restored before even the first project is built:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0"
DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="BeforeBuild" BeforeTargets="Build">
<Message Text="Restoring all nuget packages before build" Importance="high">
</Message>
<Exec Command=".\.nuget\NuGet.exe restore YourSolution.sln" />
</Target>
</Project>
If you have external package sources configure them in your nuget.config file which should
also be in the .nuget folder. For example:
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
<packageSources>
<add key="NuGet official package source" value="https://nuget.org/api/v2/" />
<add key="YourSource" value="http://yoursource.somewhere.net/nuget" />
</packageSources>
<packageRestore>
<!-- Allow NuGet to download missing packages -->
<add key="enabled" value="True" />
<!-- Automatically check for missing packages during build in Visual Studio -->
<add key="automatic" value="True" />
</packageRestore>
</configuration>
As of version 1.13.0.0 (released March 23, 2013) Fody is a 100% nuget deployed tool and as such it will work with package restore.
https://nuget.org/packages/Fody/
This will appear when you install the Fody Nuget
https://github.com/Fody/Fody/blob/master/NuGet/readme.txt
UPDATE: This answer now only applies to versions prior to 1.13.0.0.
The files in SolutionDir\Tools\Fody cannot be deployed through nuget and needs to be checked into source control
You are running into the same issue that I did when I tried to ship a build update in NuGet package. The issue is that NuGet package restore is invoked during the build process. Because of this if NuGet package restore restores a .targets file that is imported, it is restored too late. By the time the file is written to disk the <Import element has already been evaluated and skipped due to the file not being on disk.
The best thing that I have found is to build another project to invoke the package restore for you. In order to smooth this out for my own SlowCheetah NuGet package when the NuGet package is installed I create a packageRestore.proj file in the same director as the .csproj/.vbproj. Then users can build this project file and then the .sln/.csproj/.vbproj. By doing this the NuGet packages are restored and then the build process is kicked off.
If you are interested in using my packageRestore.proj I can re-factor that part of SlowCheetah NuGet package into its own and your NuGet package can depend on that one. Let me know if you are interested in that.
For background: I've got quite a nice TeamCity setup; containing a ci build and a release build which uses WiX to build my installers and patch all the version numbers. When I do a new release build, I'd like to automatically create MSP patches against a previous set of installers. I'm thinking either tagged RTM in TeamCity, or as a list of version numbers.
The approach I'm leaning towards is creating a separate config and getting the msi artifacts of all the previous builds that fit the criteria (tag or version number). Tag would seem a lot neater, but I can't see anything in the documentation about how you use it?
I've got a script to build the MSP patch, but it relies on a PCP file which needs to be edited in ORCA to describe the patch.
In terms of editing the PCP, is there anything else I can use other than the ORCA to edit? I've been looking at moving to the WiX method here: http://wix.sourceforge.net/manual-wix3/patch_building.htm which looks promising.
Does anyone know if you can access artifacts in TeamCity by Tag in the same or another build?
Does anyone have any other insights into automatically building/chaining MSP patch files in TeamCity?
You can build the .PCP file using the PatchCreation element in the WiX toolset. That will probably give you the necessary flexiblity necessary to create the customized .PCP files.
Sorry, don't use TeamCity.
Sorry, don't use TeamCity. :)
To add to Rob's answer:
#2. TeamCity can retrieve items by tag:
http://servername:8080/httpAuth/app/rest/buildTypes/id:bt13/builds?status=SUCCESS&tag=RTM
#3. I used the PatchCreation element (Rob suggested above) in the WiX toolset and he's right its flexible enough for this. Here is an outline of what I've built, it all seems to work quite well in testing,
The teamcity project has a number of build parameters, they are:
New version number - default as changeme, so if its not been changed it breaks the build.
Old version number - as above
New build repo - this is the buildtypeid, look at querystring for your project and it will have buildTypeId=btXX. The XX is the number that should be supplied here.
Old build repo - as above
The teamcity project has the following steps:
MSBuild runner to run build.msbuild (see below)
Run Candle on the patch.wxs to create a patch.wixobj file
Run Light on patch.wixobj to create a patch.pcp
Unpack new version (command: msiexec /q /a new.msi) -
Unpack old version (command: msiexec /q /a old.msi) - choose a different working dir
Create patch (command: msimsp -s patch.pcp p hotfix-%system.msiOldVersion%-%system.msiNewVersion%.msp -l patch.log
MSBuild to Create patch.pcp
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!--<Import Project="references\MSBuild.Community.Tasks.Targets"/>-->
<UsingTask AssemblyFile="references\MSBuild.Community.Tasks.dll" TaskName="WebDownload"/>
<UsingTask AssemblyFile="references\MSBuild.Community.Tasks.dll" TaskName="TemplateFile"/>
<Target Name="Build">
<!-- preconditions for build -->
<Error Condition="'$(msiOldVersion)' == 'changeme'" Text="Use run custom build, setting the client version of the msi"/>
<Error Condition="'$(msiOldVersion)' == ''" Text="Use run custom build, setting the client version of the msi"/>
<Error Condition="'$(msiNewVersion)' == 'changeme'" Text="Use run custom build, setting the new version of the msi"/>
<Error Condition="'$(msiNewVersion)' == ''" Text="Use run custom build, setting the new version of the msi"/>
<Message Text="Old Version: $(msiOldVersion)"/>
<Message Text="New version: $(msiNewVersion)"/>
<!-- download files from teamcity... -->
<WebDownload FileUri="http://server:8080/httpAuth/repository/download/bt$(msiOldRepo)/trunk/Path/bin/Release/en-us/installer-v-v.$(msiOldVersion).msi" UserName="download" Password="abcdefgh" FileName="downloads/oldversion.msi" />
<WebDownload FileUri="http://server:8080/httpAuth/repository/download/bt$(msiNewRepo)/trunk/Path/bin/Release/en-us/installer-v.$(msiNewVersion).msi" UserName="download" Password="abcdefgh" FileName="downloads/newversion.msi" />
<!-- fill in blanks in patch.wxs -->
<ItemGroup>
<Tokens Include="oldVersion">
<ReplacementValue>$(msiOldVersion)</ReplacementValue>
</Tokens>
<Tokens Include="newVersion">
<ReplacementValue>$(msiNewVersion)</ReplacementValue>
</Tokens>
</ItemGroup>
<TemplateFile Template="template.wxs" OutputFileName="patch.wxs" Tokens="#(Tokens)"/>
</Target>
Template.wxs used by MSBuild script
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<PatchCreation
Id="deadbeef-dead-beef-dead-beefdeadbeef"
CleanWorkingFolder="no"
OutputPath="patch.pcp"
WholeFilesOnly="no">
<PatchInformation
Description="Small Update Patch"
Comments="Small Update Patch"
Manufacturer="Your Manufacturer"/>
<PatchMetadata
AllowRemoval="yes"
Description="Hotfix"
ManufacturerName="Your Manufacturer"
MoreInfoURL="http://yourwebsite.com"
TargetProductName="Your Product Name"
Classification="Hotfix"
DisplayName="Hotfix - TBC"/>
<Family DiskId="5000"
MediaSrcProp="Sample"
Name="Sample"
SequenceStart="5000">
<UpgradeImage SourceFile="downloads\newunpack\newVersion.msi" Id="SampleUpgrade">
<TargetImage SourceFile="downloads\oldunpack\oldVersion.msi" Order="2"
Id="SampleTarget" IgnoreMissingFiles="no" />
</UpgradeImage>
</Family>
<PatchSequence PatchFamily="SamplePatchFamily"
Supersede="yes" />
</PatchCreation>
</Wix>
I'm trying to get CruiseControl.Net working with MSBuild (this is my first exposure to CruiseControl.Net). I thought I'd done the configuration correctly, however I just get the following error message when starting up:
[cc]Jun-22 20:02:55 Main - error setting config file on controller
net.sourceforge.cruisecontrol.CruiseControlException: error configuring project MyProject
at *SNIP*
Caused by: net.sourceforge.cruisecontrol.CruiseControlException: Unknown plugin for: <msbuild>
at *SNIP*
[cc]Jun-22 20:02:55 Main - error configuring project MyProject
As far as I can work out, this would appear to indicate that I'm missing the MSBuild plugin, however all documentation that I can find indicates that the MSBuild plugin has been included with CruiseControl.Net since version 1.0
I'm using the latest binary release (v 2.8.3)
Here is my config xml:
<project name="MyProject">
<listeners>
<currentbuildstatuslistener file="logs/${project.name}/status.txt"/>
</listeners>
<bootstrappers></bootstrappers>
<modificationset quietperiod="10">
<filesystem folder="C:\snip\main"/>
</modificationset>
<schedule interval="60">
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>
<workingDirectory>C:\snip\main</workingDirectory>
<projectFile>MyProject.sln</projectFile>
<buildArgs>/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>
</schedule>
<log />
<publishers />
</project>
Any advice on how I can troubleshoot this would be much appreciated.
Aggg - it appears that I have unwittingly downloaded CruiseControl, instead of CruiseControl.Net (and to make things even more confusing I was looking at CruiseControl.Net documentation)