Reputation: 23784
I'm trying to automate the building of a ASP.NET Core application that has two types of dependencies to Nuget packages that are part of the same project:
I want a build of this solution to get the latest versions of our Nuget packages and then "do the right thing."
Let's start with #1 above:
With dnu install (deprecated) I can effectively update to the latest version of a Nuget package; however, this is only if I am running dnu install in the same directory as my xproj. Why? because there are three positional (but AFAICT unnamed) arguments: package id, version, project location - so if I want to specify project location, I have to put in a version, but what to put if I want the latest? Tried * but that didn't work.
Ideally, I'd like to use the Coreclr dotnet client anyway, but that - by design - has no install option.
Now Case #2 My 'classic' assembly projects have a prebuild step using nuget update that pulls the latest nugets for our project and builds appropriately (which is analogous to my case #1).
HOWEVER, it doesn't appear that references to those projects in my ASP.NET Core application are being updated, although the ASP.NET project is rebuilt. In Solution Explorer, the versions of the dependent nugets remain at the version they were when I added them manually as references. The only way I've found to fix - even when just working in Visual Studio - is to remove the references and then re-add them (as if the 'wrap' mechanism doesn't automatically kick in).
All this makes me think that it's really not possible to completely automate this build - hoping that I'm wrong :)
Revised to include more details below
Here is the project structure as shown in Visual Studio, at the point that it all builds correctly.
Here is global.json:
{
"projects": [
"src",
"test",
"wrap"
],
"sdk": {
"version": "1.0.0-rc1-update1"
}
}
And here is the complete project.json for the API project:
{
"version": "1.0.0-*",
"compilationOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Lnl.Saas.Diagnostics": "1.0.0-*",
"Microsoft.AspNet.IISPlatformHandler": "1.0.0-rc1-final",
"Microsoft.AspNet.Mvc": "6.0.0-rc1-final",
"Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final",
"Microsoft.AspNet.StaticFiles": "1.0.0-rc1-final",
"Microsoft.Extensions.Configuration.FileProviderExtensions": "1.0.0-rc1-final",
"Microsoft.Extensions.Configuration.Json": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging.Console": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging.Debug": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging.TraceSource": "1.0.0-rc1-final"
},
"commands": {
"web": "Microsoft.AspNet.Server.Kestrel"
},
"frameworks": {
"dnx452": {
"dependencies": {
"Account.Model": "1.0.0-*",
"Account.Service": "1.0.0-*"
}
}
},
"exclude": [
"wwwroot",
"node_modules"
],
"publishExclude": [
"**.user",
"**.vspscc"
]
}
Now I rebuild the projects (not shown) that create the Nuget packages referenced in the solution above.
Then I'd like to be able to rebuild the Account solution above to pull in the updated Nugets
Note below that the Diagnostics Nuget reference did not change (neither did the ones in Service, but I forgot to expand it on the first screen shot)
If I look in the Nuget package manager UI, it's aware that there are updates, and if I use the UI they are applied.
If I run dnu restore in the package manager console, it lists the new packages but (re?)installs the previous ones - which are explicitly named in project.lock.json.
From trying to piece together documentation, I got the impression dnu restore was doing the 'right' thing here and I needed to use dnu install, which does work if I run it in the same directory as the project.json file (but if I try to run from another directory, where my automation scripts lie, I can't/don't know what to put in the version (2nd) argument, which is now required because I'm supplying a project location (3rd) argument).
The documentation at http://docs.asp.net/en/latest/dnx is sorely lacking, and when following some links, I got to the dotnet.github.io project which has better documentation (but not an obvious mention that it applies to rc2).
Lastly, and perhaps this offers some addition clues, is that on build I get a warnings (which don't appear to cause issues at runtime) like:
Warning MSB3274 The primary reference "C:...\Account\Service\bin\Debug\Account.Service.dll" could not be resolved because it was built against the ".NETFramework,Version=v4.5.2" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.5.1".
but have no idea how to resolve since I don't where/how I'm targeting the 4.5.1 framework with the API project.
Upvotes: 1
Views: 896