I have a c# project, that is using nuget-packages, for instance "System.Data.SQLite".
When I build my solution, the project is built each time.
Looking into details, it turns out that the DLLs that belong to packages (that are located in
$(SolutionDir)\packages\$(PackageName)\
) will be renewed before each build, although there is no new version on the server. This results into this each-time-building.
How do I avoid this?
Upgraded nuget.exe to v2.7 solved the problem
Related
We have a few projects within our CI environment which have been building successfully. Over the weekend, our IT team installed Azure SDK udpates, and since then, our project to not build anymore (even though they don't reference Azure).
The way we are building projects is
<MSBuild Condition="'$(BuildProject)' != ''" Projects="#(Projects)"
Properties="Platform=$(Platform);Configuration=$(Configuration);OutDir=$(TempProjectFilesPublish)\bin\;WebProjectOutputDir=$(TempProjectFilesPublish)"
Targets="Build"
ContinueOnError="false">
where #(Projects) is a reference to the Solution folder.
<Projects Include="$(BuildProject)"/>
The issue is around resolving project references. Nothing has changed over the weekend. The project references are correct, the csproj file has the appropriate values, no new projects or code changes have been made which is leading me to think something has been disrupted.
Wondering if anyone might know of any changes to MSBuild that would affect this?
This issue ended up being a bug in Azure SDK 2.3 with a conflict to Newtonsoft.JSON dll.
The SDK installs a 4.5 build version into the GAC, which is overriding any Newtonsoft references in projects to 4.0.
https://connect.microsoft.com/VisualStudio/feedback/details/850425/windows-azure-vs-tools-breaking-msbuild-for-web-projects
Microsoft have stated this will be fixed in 2.4.
I experience the same problem with Azure SDK v2.9. I've fixed the build for the moment by uninstalling "Microsoft Azure Library for .NET v2.9".
P.S.: Unfortunately, the link provided in the answer by mickyjtwin no longer works.
P.P.S.: The following question seems to be related:
Visual Studio keeps overwriting NewtonSoft.Json.DLL with an older version
It seems whenever a package is installed through nuget TFS doesn't pick up the dlls files for that pacakge and it's becoming a pain working on the project with multiple developers when new DLLs are being added and old ones updated.?
The 'packages' folder is being checked in.
I've searched google and seem to find people with the same problem but no solution.
Is there a solution to this problem?
I would suggest not checking in the packages folder, and instead enable Package Restore.
Check out TFS NuGetter, an integrated NuGet solution into TFS build process.
So I've been working on a game, and the sheer number of projects has become unmanageable. Enter NuGet.
I wanted to ensure my code would work on different devices, so I've been making these projects as Portable Class Libraries. I needed to use these on XBox, Windows, iOS, Android, and Silverlight. I created some custom custom SupportedFrameworks in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable\v4.0\Profile\Profile1\SupportedFrameworks
Specifically MonoAndroid and VSMonoTouch
I successfully turned one of these PCLs into a NuGet package, but when I try to add them to another PCL of the same profile I get this error:
Could not install package 'Framework.dll 1.0.0.0'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.0,Profile=Profile1', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
The package folder was brought down and contains a folder named: portable-win+net40+MonoAndroid16+sl40+net10+wp+Xbox40 and indeed contains the requested dll. I am able to add this dll to my project manually, so I believe this may be a bug in NuGet. I investigated this online, and found the main fix was to update NuGet, because the newest version plays nicer with PCLs. I've updated, but to no avail.
Has anyone seen this before, or am I missing something obvious? Any help would be greatly appriated =)
Thanks,
Joshua
It looks like you are using ".NETFramework" for the identifier in the XML file you put in the Profile1 SupportedFrameworks folder. This was basically a hack to get iOS projects building on Windows, but with real support for that scenario you should change that identifier to MonoTouch. Then when you create the package it should use monotouch in place of net10 for the lib/portable-x+y+z folder.
Then, as #Deepak suggests, install the nightly build of NuGet. Then you should be able to install the NuGet package into your PCL project. If you do try this, please let me know whether it worked or not. :)
I have a solution with reference to Telerik assemblies. The referenced version has been installed on the build server. The issue is that the continuous integration build always succeeded until I upgraded the Telerik assemblies in the solution and on my build server. The build now fails giving the classical:
Could not resolve this reference.
I checked my solution and everything is set to reference the specific version. The most suprising is that if I open the solution locally on the build server, everything will build without a problem... so that means the Telerik assemblies have been published somehow, but for an unknown reason, when MSBuild is called to compile the solution throught the build service, it does not work.
Any ideas?
I had the same problem after updating to the Q3 release.
To solve this, I built the solution with Logging Verbosity set to Diagnostic, and found that MSBuild never bothered to look in the Telerik folder.
So to include that folder in the build, we simply added it by adding a MSBuild argument:
/p:ReferencePath="C:\Program Files\Telerik\RadControls for WPF Q3 2012\Binaries\WPF40"
It's perhaps not the best, and needs to be updated everytime you update RadControls, but it works.
We run the build server on a x86 installation, so Telerik is located under C:\Program Files, but if you run on a x64, it's under C:\Program Files(x86), so if you run several build servers on both x64 and x86 installations, you must specify both path.
Try to remove-then-add reference to updated dlls - you can then see in proj file if there any differences with referenced assembly.
Enable verbose\diag mode for msbuild (/v:diag command line key) and check build logs. Diag mode have very detailed output about referenced library search process.
I normally find it's better to copy the referenced assemblies into the solution and reference them from there. Then the build server and other developers don't need to worry about installing that specific version and you can support multiple projects running different versions of the component.
We're building a set of several services, each service has it's own solution with associated projects. Many of these services rely on the same NuGet packages.
All the solutions have "Package Restore" enabled.
Some of the solutions refer to assemblies owned by other solutions, this is one obvious reason why we need all the solutions to refer to exactly the same versions of different NuGet Packages.
All of the services need to work together to achieve an end result. They're packaged and installed as part of a single product, which is another reason we'd like everything to be running off the same versions of the NuGet Packages
We're having trouble keeping package versions consistent between Solutions.
Currently we're manually checking and updating package versions, we're also getting occasional compilation errors because projects in one solution end up referring to different versions of the same package.
Is there a recommended way of doing this (hopefully an automatic process)?
Would we be better off without Package Restore?
Anyone have any general advice on the subject?
Thanks
Update: I created an issue for this on the NugGet project http://nuget.codeplex.com/workitem/2623
To solve this:
Create your own private NuGet server (see 1 and 2) that hosts the correct versions of the packages you use.
Configure each build system to use that server and auto update to the latest version.
Although this requires a server, it not only ensures everyone has the correct version but speeds up the downloads for build servers as well.
You could configure your TFS builds to update all NuGet packages in the solution to their latest versions using the nuget update command.
The latest versions could be from nuget.org, a local NuGet server or even a network share. Use the source parameter to define the sources you want to update from.
You can perform the build configuration via MsBuild proj files or via a TFS template.