I was testing the Asp.NET Core authentication features. The project.json is copied from the GitHub exmaple. here
NU1001 The dependency Microsoft.AspNetCore.Server.Kestrel >= 1.0.0-* could not be resolved.
Other dependencies can be successfully resolved. And I also double checked my dnvm version.
The IntelliSense in Visual Studio also shows there is no Microsoft.AspNetCore... package in dependencies.
So if I want to add
app.UseOAuthAuthentication("Google-AccessToken", options =>...);
in Startup.cs, what is the correct dependency to use?
If you want to use the nightly builds, you need to add the nightly package repositories to do so.
First you will need to use the latest rc2 nightly runtime dnvm upgrade -u latest. Beware, it will fail to restore packages really often!!
You need to add the proper nuget feeds. The official nuget feed (https://www.nuget.org/api/v2) do not contain this packages, as they are nightly builds and pretty unstable. Official nuget feed only has rc1-final packages
From my experience these feeds worked well for rc2 for me
Old (now deprecated) DNX runtime: https://www.myget.org/F/aspnetvnext/api/v3/index.json
New dotnet-cli tooling: https://dotnet.myget.org/F/cli-deps/api/v3/index.json
If you want to try out dotnet-cli you need to install it and follow the instructions in my previous answer on how to run ASP.NET MVC on dotnet-cli found here.
That being said, Microsoft.AspNetCore.Server.Kestrel uses the new naming scheme, which means it's RC2 since Microsoft.AspNet.* packages where renamed to Microsoft.AspNetCore.* some time during RC2 cycle.
If you need a stable base to play around, use rc1-final and it's versions, as they won't be updates at any time and your package restore won't fail multiple times a week due to upgrade to the runtime or packages.
The samples in the dev branch always target the nightly builds, that's some RC2 nightly build at the time of the writing. You either have use the sample in rc1-final branch or switch to rc2 nightly (runtime and packages) and wait for rc2 to be released (hopefully soon).
You can find the rc1-final version of project.json in the rc1-final tag or directly here.
Related
Background:
I have created a class library for .net core (targetting v2.2), and I have a .net core application as well (targetting v2.2).
I am trying to export the library as nuget package and install it in my application.
Here is the dependencies for my library
I am able to export it as nuget package and for now I am storing it in local nuget repo.
But when I try to install this library package in my application it's not getting installed due to package version conflict for Microsoft.Extensions.Logging. Here's package manager console output.
Issue:
I have specified the exact version for Microsoft.Extensions.Logging i.e. [2.2.0] as we could confirm that in the screenshot showing dependency for my library, then why it's getting resolved to version 3.0.0?
How could I resolve this issue?
Details about the environment:
NuGet product used (Package Manager Console): Package Manager Console Host Version 5.3.1.6268
VS version (if appropriate): Microsoft Visual Studio Community 2019 Version 16.3.8
OS version (i.e. win10 v1607 (14393.321)): Windows 10 Enterprise Version: 1809
How could I resolve this issue?
To resolve the strange behavior in your side, you should clean the nuget cache before installing that package in your current project.
(To make sure the cache is cleaned up, I suggest you go %userprofile%\.nuget\packages to check if there exists Com.lib folder within the Packages folder)
I have specified the exact version for Microsoft.Extensions.Logging
i.e. [2.2.0] as we could confirm that in the screenshot showing
dependency for my library, then why it's getting resolved to version
3.0.0?
I think the one(Com.Mylib) you want to install is not the first one you pack. I mean that you may actually build and pack several different Com.Mylib package with different content. And all of their names is Com.lib.1.0.0.nupkg.
Nuget stores all nuget cache in %userprofile%\.nuget\packages. So if I once install one PackageA in any project. The cache of PackageA is stored there. And if I open a new project trying to install the PackageA with same version(1.0.0), it actually installs the one from cache. So we will meet this strange behavior:
Nuget can recognize the Com.lib package depends on other 2.2.0 packages. But when it tries to install that package, it finds the package has existed in cache. Then he tries to install the one from cache, and I guess content of the one in cache is different from your latest one, then the issue occurs.
Suggestions:
1.When developing locally, use project reference instead of Nuget packages.
2.If you need to test the nuget package every time after packing, please make sure the package version has increased.(1.0.0=>1.0.1=>1.0.3... or beta-1.0.12, preview-xxx)
3.If you have special reason do use same version 1.0.0, please clean the cache to avoid previous cache affects current project.
Hope all above helps :)
I'm getting started with a Continuous Integration Nuget feed for my team using a network share. After each build to the dev environment, a package will be created on the network share using the versioning scheme Major.Minor.Patch.BuildNumber. Example: "MyPackage.1.1.3.16338.nupkg".
I was planning to have apps reference these packages on the local feed, and whichever package version is released to Production is published to Artifactory and considered the latest "stable" package/build.
The problem is, I know the versioning scheme doesn't conform to Semantic Versioning and I don't like the ugly build number at the end of the version.
Is there a better way to do this, so I end up with a simple 1.1.3 version to publish to Artifactory at the end of a release cycle?
Is there a better way to do this, so I end up with a simple 1.1.3 version to publish to Artifactory at the end of a release cycle?
I think the best way to do that is using versioning scheme Major.Minor.Patch instead of Major.Minor.Patch.BuildNumber, otherwise, you have to manually change the package version from 1.1.3.16338 to 1.1.3. Because there is no such option or task that we could change the package version after creation.
As an alternative, you could use nuget task NuGet custom to create the nuget package:
NuGet task:
Command: custom
Command and arguments:
pack $(Build.SourcesDirectory)\Package.nuspec -Version $(version) -OutputDirectory $(build.artifactstagingdirectory)
In this case, you can specify the nuget package version in the command line.
See This thread for some more details.
I'm getting this error when using maps in Android:
System.MissingMethodEsception: Method
'Xamarin.Forms.maps.Android.MapRenderer.OnCameraChange' not found.
And I've read that you can update the nugetpackage to fix the issue. However, I cannot install it due to this:
Could not install package 'TK.CustomMap 2.0.1'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.5,Profile=Profile78', 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 updates of packages installs just find in iOS and Android but not for PCL. I've tried to remove all the packages and then tried to add TK.Customs nuget package but this same issue.
Also tried to install it on a fresh project and that installed just fine. Just cant get it to install on my old project.
Here is the whole error message when trying to update package:
Attempting to gather dependency information for package 'TK.CustomMap.2.0.1' with respect to project 'Vernamo', targeting '.NETPortable,Version=v4.5,Profile=Profile78'
GET https://api.nuget.org/v3/registration3-gz-semver2/tk.custommap/index.json
OK https://api.nuget.org/v3/registration3-gz-semver2/tk.custommap/index.json 175ms
Total number of results gathered : 29
Gathering dependency information took 232 ms
Summary of time taken to gather dependencies per source :
https://api.nuget.org/v3/index.json - 204.03 ms
Attempting to resolve dependencies for package 'TK.CustomMap.2.0.1' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'TK.CustomMap.2.0.1'
Resolved actions to install package 'TK.CustomMap.2.0.1'
Found package 'TK.CustomMap 2.0.1' in '/Users/holger/Downloads/Vernamo/packages'.
For adding package 'TK.CustomMap.2.0.1' to project 'Vernamo' that targets 'portable45-net45+win8+wp8'.
Install failed. Rolling back...
Package 'TK.CustomMap.2.0.1' does not exist in project 'Vernamo'
Executing nuget actions took 52 ms
Could not install package 'TK.CustomMap 2.0.1'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.5,Profile=Profile78', 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 pre-release version (at least pre2) of TK.CustomMap supported all platforms (see here), anyway, as of pre3 (see here), obviously the support for all platforms was dropped in favor of .NET Standard (1.1 in this case).
The profile you are using in your PCL does not seem to be compatible with .NET Standard 1.1, hence NuGet fails to add the reference. You may try to switch to another profile (.NET 4.5.1 for example), but I don't know if that would help. Another option would be to migrate your projects to .NET Standard. It's kind of a stupid, repetetive task, but it's possible.
Since Visual Studio 2017 is released and we can use the new C# 7 features I expected this will work when deploying on Azure Web apps.
Unfortunately we're seeing compile errors when using continuous deployment (kudu git deploy) so it seems Azure doesn't support the new toolchain yet.
Is there anything we can do to get this to work now (besides publishing the assemblies directly)?
since we don't yet have msbuild15 in Azure.
if you want to use c#7 features with continuous integration, you may need some workaround
for dotnet core web solution, you can build it in Azure out of the box. (it uses its own dotnet msbuild.dll) [repository sample]
for asp.net web solution, you need to add Microsoft.Net.Compilers 2.0+ nuget package to the project where the new language feature is applied. For example, if a class library in the solution is using the new syntax, you need to add nuget package to that lib project. (the new c# compiler is thus imported if you refer this nuget package) [repository sample]
finally for mixed solution (dotnet core web app + .NET framework class lib), you need to run nuget restore for the .NET framework lib project independently since dotnet restore is not backwards compatible, it cannot retore project from the old build system. I did this by hacking my deploy.cmd [repository sample]
these workarounds either try to
imitate msbuild15 (case1: dotnet msbuild.dll, case2: compiler as a nuget package)
or imitate nuget4.0 (case 3: run both dotnet restore and nuget3.5 restore)
we are in the process of building these tools for Azure, they should be out soon. you can stay updated on github
Adding the Microsoft.Net.Compilers NuGet package fixes the issue.
As pointed out by #joshuanapoli in a comment to the accepted answer Scenario #2 works only with Microsoft.Net.Compilers v2.4.0 and below.
Took me a couple of hours to notice and figure it out.
Should we put our nightly builds on NuGet daily? Customer asked for this but they are a big number of packages per year. Is NuGet designed for this purpose? How can we mark stable releases instead?
Thanks.
First of all, think from the users point of view.
Even if a customer installs your nightly, he will be able to go back to a more stable nightly if something breaks. For this an absolute requirement is a unique version scheme for every build that you publish.
Let's say your customer has version 1.0.1-nightly.1234 installed which works for hin. Now he does an update to 1.0.1-nightly.1235 which is broken and he can not continue. He should be a able do do
uninstall-package YourPackage
install-package YourPackage -version 1.0.1-nightly.1234 -pre
I understand that you don't want to mess up nuget.org with your nightly builds so you could either use another feed or setup your own sever (maybe your build server already can do this, I use teamcity which can do nuget deploys and has a build in nuget server, even if I never used it so far but am planning to do so).
Maybe you can do a monthly pre-release on nuget.org or manually publish nightly builds that you consider fairly stable.
I would suggest you change your version scheme to include a date in your builds 1.0.1-nightly.20140520 for your own feed and 1.0.1-nightly for the official build.
nuget itself supports versioning schemes like <major>.<minor>.<patch>-<buildname>.<revision> but nuget.org only allows <major>.<minor>.<patch>-<buildname>
http://docs.nuget.org/docs/reference/versioning
There is nothing stopping you from putting your nightly builds on NuGet. Some teams, such as the ScriptCS team and the ASP.NET team use MyGet for nightly builds instead of using the main NuGet feed.
You will probably want to distinguish these builds from stable releases, at least on the main NuGet feed. You would need to mark these builds as pre-release NuGet packages using a version number such as 1.0.1-alpha1 and use 1.0.1 for the stable release. However if you use MyGet you would not need to mark these builds as pre-release if you did not want to.