I created nuget package yet while
PS C:\Users\vicky\Documents\ThreadBasedJobQueue\Testnuget> dotnet add package abhi.TaskQueueLib --version 1.0.0
Writing C:\Users\vicky\AppData\Local\Temp\tmp44DF.tmp
info : Adding PackageReference for package 'abhi.TaskQueueLib' into project 'C:\Users\vicky\Documents\ThreadBasedJobQueue\Testnuget\Tes
tnuget.csproj'.
log : Restoring packages for C:\Users\vicky\Documents\ThreadBasedJobQueue\Testnuget\Testnuget.csproj...
info : GET https://api.nuget.org/v3-flatcontainer/abhi.taskqueuelib/index.json
info : OK https://api.nuget.org/v3-flatcontainer/abhi.taskqueuelib/index.json 1139ms
info : GET https://api.nuget.org/v3-flatcontainer/abhi.taskqueuelib/1.0.0/abhi.taskqueuelib.1.0.0.nupkg
info : OK https://api.nuget.org/v3-flatcontainer/abhi.taskqueuelib/1.0.0/abhi.taskqueuelib.1.0.0.nupkg 1424ms
log : Installing abhi.TaskQueueLib 1.0.0.
error: Package abhi.TaskQueueLib 1.0.0 is not compatible with netcoreapp2.0 (.NETCoreApp,Version=v2.0). Package abhi.TaskQueueLib 1.0.0
supports: root (Root,Version=v0.0)
error: Package 'abhi.TaskQueueLib' is incompatible with 'all' frameworks in project 'C:\Users\vicky\Documents\ThreadBasedJobQueue\Testn
uget\Testnuget.csproj'.
The following documentation has the answers you are seeking:
https://learn.microsoft.com/en-us/nuget/create-packages/supporting-multiple-target-frameworks
Irrespective of whether you target one framework or multiple frameworks, you should create the ‘framework’ folder under the lib directory and then put the dll into that framework folder. This folder for the target framework is called Target Framework Moniker or TFM in short. List of all the allowed TFMs for NuGet is captured here:
https://learn.microsoft.com/en-us/nuget/schema/target-frameworks#supported-frameworks
Found the issue in lib folder i had to make folder by framework Name and then had to pack.
Un knowing i was keeping my Dll in Lib Folder
please refer https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package
Related
I used NuGet Package Explorer (for the first time) to create a .nupkg to share with others. I have one DLL that targets NetStandardLibrary 2.0,
But when I try to add the package I receive the following error:
Could not install package 'iCANMVCSDK 1.0.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.7.2', 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.
I thought that by using NETStandard 2.0 it could be installed in any .NET app. I also tried adding additional assemblies:
I rebuild, repackage, and I still get the same error. What am I missing?
I tried editing the project file like this:
<TargetFrameworks>netstandard2.0;net472</TargetFrameworks>
When I try to build after adding net472, I receive the following error:
The type or namespace name 'Http' does not exist in the namespace 'System.Net'
What really makes no sense to me is that I can add the DLL directly into the project (the one that targes NET 4.72) and it works as expected. The problem is when attempting to install it as a NuGet package.
I've added a Nuget-package to my .NET Core "Azure Function"-project:
Install-Package SharePointPnPCoreOnline -Version 2.22.1801
But I receive an error in my code:
Microsoft.Azure.WebJobs.Host.FunctionInvocationException : Exception
while executing function: StoreInDatabase --->
System.IO.FileNotFoundException : Could not load file or assembly
'SharePointPnP.IdentityModel.Extensions, Version=1.2.3.0,
Culture=neutral, PublicKeyToken=5e633289e95c321a' or one of its
dependencies. The system cannot find the file specified.
This assembly should be included from the Nuget Package, but it doesn't.
As I'm new to .NET Core and Azure Functions, does anyone know how to solve this one?
Update
I see the package has another version number than in the error-details.
But still no idea how to solve this... any ideas?
Looking at the nuget package with the wrong version number, I saw that previous versions are "hidden" in NuGet...
https://www.nuget.org/packages/SharePointPnP.IdentityModel.Extensions/
I solved this by installing the latest version of the package
So in my case, I just ran the command:
Install-Package SharePointPnP.IdentityModel.Extensions -Version 1.2.3
I've a custom NuGet package (My.Resources) containing an assembly and a dependency on another custom NuGet package (My.Base).
If I install the package, the installation finishes successfully, but the assembly reference is not added. Here is the full output from a Install-Packagecommand:
Attempting to resolve dependency 'My.Base (≥ 1.0.0)'.
Installing 'My.Base 1.0.0'.
Added file 'My.Base.dll' to folder 'My.Base.1.0.0\lib\net45'.
Added file 'My.Base.1.0.0.nupkg' to folder 'My.Base.1.0.0'.
Successfully installed 'My.Base 1.0.0'.
Installing 'My.Rsources 1.1.0-beta0001'.
Added file 'My.Resources.dll' to folder 'My.Resources.1.1.0-beta0001\lib\net45'.
Added file 'My.Resources.XML' to folder 'My.Resources.1.1.0-beta0001\lib\net45'.
Added file 'My.Resources.1.1.0-beta0001.nupkg' to folder 'My.Resources.1.1.0-beta0001'.
Successfully installed 'My.Resources 1.1.0-beta0001'.
Adding 'My.Base 1.0.0' to WindowsFormsApplication8.
For adding package 'My.Base 1.0.0' to project 'WindowsFormsApplication8' that targets 'net45',
>> Assembly references are being added from 'lib\net45'
Added reference 'My.Base' to project 'WindowsFormsApplication8'
Added file 'packages.config'.
Added file 'packages.config' to project 'WindowsFormsApplication8'
Successfully added 'My.Base 1.0.0' to WindowsFormsApplication8.
Adding 'My.Resources 1.1.0-beta0001' to WindowsFormsApplication8.
Added file 'packages.config'.
Successfully added 'My.Resources 1.1.0-beta0001' to WindowsFormsApplication8.
While we have several other custom NuGet Packages structured and build the same way, this is the only one with this behavior. The .nuspec inside the .nupkg looks fine and the assembly is in the correct (net45) folder.
NuGet is treating your NuGet package as a localized NuGet package that only contains language resources. Assemblies in this sort of NuGet package are not referenced.
If you rename your My.Resources.dll to something like My.Resources2.dll, for example, then NuGet will reference the assembly.
Basically any file that ends with .resources.dll is considered by NuGet to be a resource assembly will not be referenced when the NuGet package is installed.
I've imported the Hangfire Source code from Github into my existing VS 2013 solution. When I attempted to build all projects within my solution, I get several errors:
Error 6 The type or namespace name 'Dapper' could not be found (are you missing a using directive or an assembly reference?) C:\Users\Jerry_Dev\Documents\GitHub\Hangfire\src\Hangfire.SqlServer\SqlServerDistributedLock.cs 20 7 Hangfire.SqlServer
In Package Manager, when I do: "Install-Package Dapper", it says
'Dapper 1.38' already installed.
Hangfire.SqlServer already has a reference to 'Dapper 1.38'.
I see Dapper dot net installed in my Manage Nuget Packages Window in my Hangfire.SqlServer project
We don't store the packages folder under source control to reduce the source code size. Hangfire uses Automatic Package Restore in Visual Studio instead of obsolete MSBuild-integrated package restore. The Automatic Restore downloads missing packages automatically on each build, but it works only with NuGet ≥ 2.7, so you have the following options:
Update NuGet to the latest version
Please see the official docs.
Run the build script
Go to the root Hangfire directory and run the build.bat file. It will automatically restore all the missing packages.
Example:
Nuget package A is a set of code snippets (it does not contain an assembly).
Nuget package B is a normal assembly and it is using package A - just for internal means.
Question: What can I do, to avoid, that package A is also installed, when somone installes package B?
Found something in documentation of nuget:
Starting from version 2.7, the pack command will ignore entries in the packages.config file which have an attribute developmentDependency set to true and will not include that package as a dependency in the created package. For example, consider the following packages.config file in the source project
That seems to solve the problem.