On my development machine i have successfully configured visual studio for telerik's package source. Based on our current license it shows the latest Telerik.UI.for.AspNet.Core package we can download is version 2016.3.1118 (along with other old versions)
So on development machine i installed the version 2016.3.1118 and tested successfully.
Now, i am trying to publish the solution on our Jenkins build server. Jenkins executes the following command to restore packages and publish
dotnet publish wmp.sln -c Release
However, Im getting error on the build server
error NU1102: Unable to find package Telerik.UI.for.AspNet.Core with
version (>= 2016.3.1118) [D:\Jenkins\wmp\workspace\wmp.sln]
error NU1102: - Found 1 version(s) in nuget.org [ Nearest version:
2016.3.914 ] [D:\Jenkins\cr-wmp\workspace\wmp.sln]
UPDATE 1
I use the instructions to setup Telerik's Nuget Package Feed
(Note that i do have another ASP.NET Core project that is using version 2016.3.914. This project also configured with another Jenkins Job for CI. and it has no issue restoring and publishing)
Your error says
error NU1102: - Found 1 version(s) in nuget.org
which means it's not checking Telerik's package source. You didn't explain exactly how you added the source, but given the message quoted above, and you said you "configured visual studio", I assume you used the NuGet->Package Sources UI in Visual Studio's Tools->Options. Unfortunately NuGet's options dialog only supports user profile settings, not NuGet's hierarchical settings capability. Therefore using the VS UI to add the source makes it available for every solution on your user account on that computer, but not other accounts on the same computer, or when that solution is used on another computer.
You should create a nuget.config in your repository and use the packageSources to specify your package sources. If you have the .NET Core SDK installed on your machine, you can use dotnet new nugetconfig to create the file from a template. Once you have a nuget.config with your package sources configured checked into your source code repository, when it's checked out on the CI agent, NuGet will know to check Telerik's feed on restore.
Related
We're just in the process of transitioning from VS2013&15/TFS2013 to VS2017/TFS2017 (on-site TFS, not VSTS) and the first test solution is a dotNet Core 1.1 based one (a multi-project web service).
The solution builds fine on the original developer's box and I've got it out of TFS and it builds fine on mine too. In keeping with our previous methodology the contents of the packages folder are checked in with the projects as this makes the packages locally available on the build box (no internet).
Building the solution on the build server is a different story, however, as I get multiple errors of the form...
..\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
This whole project.assets.json not found issue seems to be causing headaches all over. In my case the issue is that I'm trying to resolve it on our TFS 2017 Build Server, which does not and never will have internet access ('cos it's a server!).
All the solutions I've seen thus far seem to suggest running the Nuget Restore command but that can't work since the server cannot get to nuget.
This is nothing fancy yet, just a simple TFS 2017 Build definition with a Get sources and a Build solution step. I can't understand how something so simple has become so difficult.
Changing the Nuget Package Restore options makes no difference.
Since the project.assets.json files are generated on the fly in the obj folder, I can't even check them in to reuse. Can anyone please suggest a workaround, at the moment the test project is dead in the water.
Edit: trying the same process with a 4.6.1 web project created with VS2015 had similar results of unresolved references (e.g. System.Web) but didn't raise the same error, probably due to being an older, non-Core project.
According to I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
The issue seems not related to TFS build side since it also not work with local build through VS in the build agent machine.
Since this is a dotnet project. So, you could try to use “dotnet restore” and not “nuget restore”. Try using the dotnet core template (which uses dotnet restore).
If you are using authenticated nuget feeds, then you can use nuget restore but you also need to use nuget installer task. See https://github.com/Microsoft/vsts-tasks/issues/3762 for a discussion on that.
The Nuget version should be higher than 4.0.
Without dotnet restore and Nuget restore and only use get source/Visual Studio Build will not be able to build the dotnet core project. If your server do not have internet access, as a workaround you should use Local feeds.
I am trying to build my Xamarin.iOS application on my Mac using Visual Studio Team Services (was Visual Studio Online) and the VSTS Build Agent (https://github.com/Microsoft/vsts-agent)
When my Xamarin.iOS project comes to build it starts to restore the nuget packages and then errors with the following error:
'MvvmCross.Core' already has a dependency
defined for 'MvvmCross.Platform'.
'MvvmCross.Tests' already has a dependency defined for
'MvvmCross.Platform'. 'MvvmCross.Binding'
already has a dependency defined for 'MvvmCross.Core'.
I found this post on nuget Error installing MvvmCross.HotTuna.MvvmCrossLibraries v4.0.0-beta1 in Xamarin Studio
which said that this may be caused by old nuget clients.
The current nuget client on my mac is V2.8.6 so I upgraded the nuget client using
nuget update -self
which updated to V3.4.4
But now I am getting the error:
MSBuild auto-detection: using msbuild version '4.0' from
'/Library/Frameworks/Mono.framework/Versions/4.4.0/lib/mono/4.5'.
MsBuild.exe does not exist at
'/Library/Frameworks/Mono.framework/Versions/4.4.0/lib/mono/4.5/msbuild.exe'.
Is this a bug with Nuget / MvvmCross or the VSTS agent?
You can add the latest version of Nuget.exe to your repository and also add a shell script to execute it and restore Nuget packages on a Mac build server. The shell script would simply have a line similar to:
mono nuget/nuget.exe restore $1
The $1 is a parameter that is passed to the shell script and should point to the solution file you want to restore packages for. nuget/nuget.exe should point to the nuget restore file you added to the repository.
Then in VSTS instead of using the default Nuget restore task, add a shell script task and point it to the shell script in your repository and the parameter should point to the solution file.
Just make sure your build server can also find the mono command.
I wrote this post explaining the solution in more detail:
Xamarin Build Services - Nuget Restore with VSTS
Ok so I ended up Refactoring out MvvmCross for MvvmLight and now it works.
This isn't the ideal answer as it took me about 2 and a half days to refactor out MvvmCross from my project. But the code feels a lot simpler now and I have managed to get rid of alot of complexity and...
My Automated iOS build now works!
In future I will be picking MvvmLight over MvvmCross as an Mvvm Framework
Instead of upgrading the nuget to the latest version, please try to update the nuget addin for Xamarin to 2.8.7 by following the steps in this link: Can I update the Nuget.Core.dll used by Xamarin Studio? which should fix your first problem. Nuget 3 has some issues on non Windows OS, check this page for details: NuGet Compatibility
As you know NuGet uses %LOCALAPPDATA%\NuGet\Cache location for caching. It first checks if requested packages is here then download if needed.
How can I properly disable this cache mechanism from Nuget and "Visual Studio 2013", and make sure they always download from sources?
Can I build Nuget Package Manager Extension from source, then install it to Visual Studio? Or Are there any registry configuration that disable it?
Thanks
You cannot disable NuGet from using a cache. The only thing you can do without changing the source code is to change the location of the cache directory using a NuGetCachePath environment variable.
So you are left with clearing the local cache manually or automatically before installing a NuGet package or modifying the source code for NuGet's Visual Studio extension.
The source code for NuGet 2.8.5 and older is available on CodePlex.
The source code for NuGet 3.0 is available on GitHub
There are some instructions available on how to setup the NuGet development environment to be able to build and run NuGet within Visual Studio.
Currently it's possible to do so in case you'd running Install NuGet packages task through CLI which is common practice.
You can order NuGet to not use it's cache at all by using -NoCache input parameter. Then it will behave as you described. See CLI reference of NuGet.exe
I use Visual Studio 2013, and am building on TFS 2012 (update 3). I have a relatively small project that builds fine locally as well as on other machines on which I simply get the latest version from source control. When I build on the build server however I get several of the following errors:
The type or namespace name 'xxx' does not exist in the namespace 'yyy' (are you missing an assembly reference?)
Several of these errors are thrown for different namespaces, including Entity and other NuGet packages.
At first I thought that the build server was not restoring the NuGet packages, but after some investigation it seems that the packages are in fact downloaded onto the build server.
I have set up automatic package restore in VS and added the system environmental variable "EnableNuGetPackageRestore = true". To double check, I manually executed the following restore command on the server:
nuget.exe restore fullpath_to_solution\solution_name.sln
and the output was:
All Packages listed in packages.config are already installed
Then I thought that since TFS is older (2012) than VS (2013), perhaps I need to install .Net 4.5.1. But as it turned out, .Net 4.5.1 was already installed on the build server.
Any suggestions on how to get this project to build on the server?
Could be many issues, possibly proxy.
Log on to build server with build account.
Try building the solution in VS.
See if packages are restored on build.
You should then be able to trace the issue.
The best idea is to delete the contents in your workspace, then build to make sure all packages are restored properly before checking in
Our build plans for Sitecore (.Net) websites are currently using Bamboo as the build plan master for continuous integration process. Bamboo supports building a .Net project, and that .Net project contains references to several Sitecore binaries.
I have used NuGet as an artifact repository, mostly because that seemed to be the one most people were using.
So, now that I have a nuget repository, am hosting my own feed, and have added the Nuget package to my project (I just installed the package of binaries I created), what more do I need to do?
Should the build call out something special, or am I done? I guess I'm just nervous that bamboo isn't talking directly to my repository....
In the closest analogy I have, namely a Maven/Archiva combo, the maven plan specifically references the artifacts in archiva, pulling the correct version as needed. Does NuGet do this?
Since there have been some new developments in the NuGet package restore approach, I thought I'd post an update on this topic. We're using Visual Studio 2012. I wanted to be able to run MSBuild and make sure that it would first restore NuGet packages without setting "Package restore" to true in the config. Here's what I did (inspired by https://stackoverflow.com/a/23935892/414376):
Upgraded NuGet in my solution to a version later than 2.7 (2.8.3 in my case; this seems like an optional step)
Installed NuGet.exe on the build server
Added NuGet.exe to my remote agent so that it could be run as a command from Bamboo
Added the NuGet command to my build plan with argument restore (so that the command will be nuget restore); I've placed it right before my MSV Build task.
That was all I needed to get this to work properly according to the latest guidelines.
Nuget 1.4+ supports "Package restore" which embeds a call to an MsBuild task in the project file. When the packages are not available it will automatically restore them while building the project.
I'm sure this is old news, but my packages are in \packages. No amount of "dotnet restore" would work, until I explicitly mentioned the packages folder.
dotnet restore --packages .\packages
restored them!
VS2019. just in case it's version specific.