I would like to add an XSD file to a Nuget package. When a project installs the Nuget package, this file should be included in the project, in order to allow Intellisense in the project's app.config file.
I can add the XSD to the Nuget package just fine, but I don't know how to make it show up in the project that uses the dependency.
Can this be done?
FWIW There are some extra sections injected in the project's app.config file (via Nuget's "transform" capability). The XSD offers Intellisense for those extra sections, and Visual Studio automatically picks up XSD schemas included in the project (or even solution) that match the declared namespace of the XML elements.
Nuget has the option to run custom install Powershell scripts that get a reference to the project that is installing the package.
Details:
http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package#Automatically_Running_PowerShell_Scripts_During_Package_Installation_and_Removal
Here are some usage examples:
http://www.codeproject.com/Articles/209522/PowerShell-Script-Examples-for-NuGet-Packages
Related
So I installed TinyIoC v1.3.0 using nuget in my Xamarin.Android project, its in the references, but I cannot type using TinyIoC; without a compile error. I would like to understand why this is?
PS. I know I can use the TinyIoC.cs file directly, but I thought it would be more convenient to update if I added using nuget.
I get this error:
I think the issue is related to the nuget package TinyIoC 1.3.0 itself.
The nuget package does not contain the lib folder with the related dll so that you can not use the format by using namespace.
Note: Important
The nuget package contains a folder called Content. This folder will copy its content into the main project with packages.config when you install the nuget pacakge. See this similar issue on so.
And it will make TinyloC.cs file directly in your main project and you can just modify it there.
I have created a net framework project with packages.config format.
However, since your project is xamarin andorid app, it uses PackageReference nuget manage format, and content folder does not work for it. Instead, you should use ContentFiles folder, but this nuget package does not contain it.
To make this issue more clearly, you should contact the author of the nuget package to report this problem.
I need my Visual Studio C# library published to NuGet with a custom name from command line.
As far as I understood there is only one way to do it - using .nuspec file with the ID specified. This is what I wouldn't like to do because I'd have to manually fix the file on every project change. I also was not able to find a tool who generates a .nuspec (with dependencies) from a .cproj file.
I've been looking and the nuget pack options, but only found -Properties who seems not to do the job.
I also was not able to find a tool who generates a .nuspec (with
dependencies) from a .cproj file.
As far as I know, there's no easy tool(nuget spec command does't support doing that) to generate the .nuspec with package dependencies from a xx.csproj. And since your actual question is Set custom ID for a NuGet package **without** using .nuspec, I won't talk about how to generate and modify it here.
I've been looking and the nuget pack options, but only found
-Properties who seems not to do the job.
I assume you're using a .net framework project that uses PackageReference format. Since you're not willing to use .nuspec file, you have to use nuget pack xx.csproj or nuget pack(run this command in where the csproj exists) command.
But as I know there's also a known issue that nuget pack won't show dependencies when using this command with projects that use PackageReference format. And yes, nuget pack -Properties won't meet your needs for your current project type. So it's not a good choice.
Set custom ID for a NuGet package without using .nuspec
Suggests for your original question:
Since you don't want to use .nuspec file, nuget pack is not an option for your situation. To create a nuget package, nuget.exe is not your only choice. You can also consider dotnet CLI and MSBuild.exe.
1.You can choose to change your project from non-SDK format to new SDK format, then you can specify the ID in project file(.csproj), and you don't need a .nuspec any more. Also, after the migration, it will support specifying the ID in command-line.
So you can use command like dotnet pack -p:PackageID=TestName to specify the ID(or other package metadata) in command-line easily. (For sdk format, you can also use msbuild.exe)
2.If you don't want to change your current project format to SDK format, you can follow this topic: If you are using MSBuild with a non-SDK-style project and PackageReference, add the NuGet.Build.Tasks.Pack package to your project.
Consume that package and then use command msbuild -t:restore to restore nuget packages in command-line. Then use command like msbuild -t:pack -p:PackageID=xxx to specify ID in command-line.(Or set that ID in xx.csproj)
I created a setup project using Microsoft Visual Studio Installer Projects (0.9.3, this is latest for Visual Studio 2019). After setup is executed it installs Nuget package assemblies that are different from the assemblies generated during build.
Why is it doing that and how can I make it to chose assemblies consistent with build assemblies?
My application is for 4.7.2 framework. Typical example is System.ValueTuple.dll (4.0.2)
Build retrieves assembly from:
C:\Users\.nuget\packages\system.valuetuple\4.5.0\lib\net47\System.ValueTuple.dll
Install retrieves assembly from:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.7.2\Facades\System.ValueTuple.dll
While install based on 4.0.2 creates a concern but works, when I upgrade nuget package to version 4.6 (and assembly to 4.0.3) install switches to using assembly C:\Users\vgdev.nuget\packages\system.valuetuple\4.5.0\ref\net47\System.ValueTuple.dll
If you look closer, you will notice path above has \ref folder and it contains "reference" assembly. Reference assemblies are not meant to be installed and cause errors BadImageformatException.
The build after Nuget package upgrade continues to pull packages from the correct \lib folder and application works fine. So what I want to do is to make installer work consistently with build. Any advice?
Install retrieves assembly from: C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.7.2\Facades\System.ValueTuple.dll
Which way do you reference that package? I can only reproduce this issue when I add reference manually.(Right-click project=>Add reference=>Browse...) If you're doing so, please remove that reference, and add that reference back by Nuget Package Manager UI.
My application is for 4.7.2 framework. Typical example is
System.ValueTuple.dll (4.0.2). When I upgrade nuget package to version 4.6 (and assembly to 4.0.3)
I can only find it with latest 4.5.0 here. And I think it contains the assembly version 4.0.3 instead of 4.0.2.
(I guess something corrupts the process when VS recognize your assembly version cause in most machines it displays 4.0.3 while in one machine, it displays 4.0.2, quite strange...)
The build after Nuget package upgrade continues to pull packages from
the correct \lib folder and application works fine. So what I want to
do is to make installer work consistently with build. Any advice?
Cause of the issue:
This strange behavior may have something to do with Setup project. I can reproduce same situation and I found this issue only occurs when I use PackageReference format to manage nuget packages in my application.(.net 4.7.2)
PackageReference format is the new nuget package manage format after VS2017. I'm not sure if the Setup project fully support for it.
Here're two suggestions which may help:
1.I found this issue only occurs when using PackageReference format. So you can try using Packages.config format in your application. And I've checked the setup project can recognize this format well.
Uninstall all PackageReference format packages, and go Tools=>Nuget Packages Manager=>Nuget Package Manager to set the Allow format selection... to true.
Clean all nuget cache and click ok. After that delete bin and obj folders, then restart VS to add those packages back using Packages.config format.
2.If you continue to use PackageReference format. Try excluding the assembly from ref folder, and manually add that from lib folder by Add=>Assembly=>Browse.
Note: Since Setup project may not fully support packageReference format projects, actually I think #1 could be more suitable for your situation. And you can create a new simple project with packages.config format to check if the issue can be resolved by Packages.config format. Hope it helps :)
It seems that the root cause of the problem is the usage of the BuiltProjectOutputGroupDependencies target by visual studio setup projects instead of the ReferenceCopyLocalPathsOutputGroup target (see PackageReferences put ref instead of lib assemblies in the output group used by VS installer projects).
The proposed workaround is to overwrite the BuiltProjectOutputGroupDependencies target at the end in the project file of your main project:
<Target
Name="BuiltProjectOutputGroupDependencies"
DependsOnTargets="$(BuiltProjectOutputGroupDependenciesDependsOn)"
Returns="#(BuiltProjectOutputGroupDependency)">
<ItemGroup>
<BuiltProjectOutputGroupDependency Include="#(ReferenceCopyLocalPaths->'%(FullPath)');
#(ReferenceDependencyPaths->'%(FullPath)');
#(NativeReferenceFile->'%(FullPath)');
#(_DeploymentLooseManifestFile->'%(FullPath)');
#(ResolvedIsolatedComModules->'%(FullPath)');
#(ReferenceComWrappersToCopyLocal->'%(FullPath)')"/>
</ItemGroup>
</Target>
I have a proof-of-concept solution that has a .NET Standard project in it. I use Paket to manage my nuget dependencies. I am able to use paket add and dotnet restore, per these instructions, to add a nuget dependency to that project. When I reopen my solution, I see that a paket.references file has been added to that project, and that a "NuGet" section has been added under the project's "Dependencies" section in "Solution Explorer".
I'm curious, how does VS2017 know what dependencies to list that "NuGet" section?
From the instructions I linked to above:
In contrast to traditional .NET projects Paket will not add assembly
references to your project files. Instead it will only generate a
single line:
<Import Project="..\..\.paket\Paket.Restore.targets" />
This hook tells the .NET SDK to restore packages via Paket's restore
mechanism. A nice benefit is that your project files are now much
cleaner and don't contain many assembly references.
I'm sure I'm missing something, but I don't see anything in Paket.Restore.targets that would tell Visual Studio where to look to find the dependency chain of the nuget package I added to the project. There are no direct references to any dependencies mentioned in the project file.
For context, I have a repo where I'm trying to add a .NET Standard project to a solution that is full of .NET Framework projects. I'm running into an issue where paket add seems to correctly create a paket.references file for the new project, but dotnet restore doesn't seem to be causing the project references to update, resulting in my project not having a reference to the nuget dependency I'm trying to have it reference. I'm having trouble creating a reproducible example (my proof-of-concept seems to be working fine), so I'm trying to better understand how this infrastructure works to help with debugging.
I've known about copy/paste references in Visual Studio since 2010/2012. Has this been updated to work with Core 2?
Here's the SO Question asking about the old style references (before Core, and before the reboot of csproj format): Is it possible to copy / paste References from one project to another in Visual Studio?
Maybe now that dotnet add package is available, we don't need copy/paste references in VS?
"Add Google social login" walkthrough for ASP.NET Core 2.0 suggests using the dotnet CLI to add a package reference:
To install with .NET Core CLI, execute the following in your project
directory:
dotnet add package Microsoft.AspNetCore.Authentication.Google
source: https://learn.microsoft.com/en-us/aspnet/core/security/authentication/social/google-logins?tabs=aspnetcore2x
Writing this answer to my own question so the "just use the CLI" folks have something to upvote.
If you are talking about NuGet package references, don't try to copy the resolved references to dll files manually (the are generated from the obj\project.assets.json file during the design-time build after loading the project).
In the new SDK-based project model and the PackageReference way of referencing NuGet packages (also available for "classic" projects), NuGet references automatically flow transitively across package references. So when your app references a library that uses a NuGet package, you no longer need to install the NuGet package in both the library and the app (and potentially test projects).
Only for "classic" references, this issue remains. However, if you need to import them into all projects (say you got a few .dll files from a 3rd party), you can create a Directory.Build.targets in the solution folder to add them to all projects in your solution (technically, this file is automatically imported into all projects in the directory hierarchy):
<Project>
<ItemGroup>
<Reference Include="AssemblyName">
<HintPath>shared-libs\AssemblyName.dll</HintPath>
</Reference>
</ItemGroup>
</Project>
(you may want to change the reference if you want the "specific version" feature or strong-name references as described in https://stackoverflow.com/a/16580870/784387)