The NuGet docs describe two possible repositories for package files defined within a VS template: 1) within the VSIX, or 2) within the template. There's also the third option of the registry for "installed" packages.
We have custom project templates which will use publicly available NuGet packages which are not already defined in the registry. It will bloat the VSIX and/or templates too much to include the nupkg files too. Is there some hidden option or trick to allow the repository to instead point to the package source(s) as defined by the Visual Studio user?
Since I didn't find any easy "trick", I wrote a custom project wizard per this discussion - http://nuget.codeplex.com/discussions/385955.
The package sources can be found via the PackageSourceProvider, which you can import via MEF along with the PackageInstaller. You then create a repository from the package sources, and pass it to the installer:
var factory = NuGet.PackageRepositoryFactory.Default;
var packageSources = PackageSourceProvider.LoadPackageSources().Select(s => s.Source).ToList();
var repository = new AggregateRepository(factory, packageSources, true);
NuGetPackageInstaller.InstallPackage(repository, project, package.Id, package.Version, false, false);
Calling InstallPackage directly also allows you to install dependent packages and assembly references, both of which are disabled by the standard NuGet VSIX package installer.
I'm guessing standard NuGet doesn't allow the dependencies to be installed for security reasons, but in our case we're using our own VSIX, our templates, and our NuGet packages, with a few additional known dependencies, so the license check has been made long before the template is actually used.
Related
I am working on a nunit engine extension which will be shipped as a nuget package.
Following the advises in How to implement NUnit's NUnit.Engine.ITestEventListener i was able to write the extension.
This solution is working as long as the project which contains the extension (the .cs file as well as the .addins file) is being imported to the target project which will perform the nunit tests.
As soon as I create a nuget package (following Quickstart: Create and publish a NuGet package using Visual Studio (.NET Standard, Windows only)) from the extension project and install this package to a test project, the extension doesn't work anymore.
I assume there is a problem with providing the .addins file within the nuget package so that the nunit engine in the target project can find the extension.
I already tried to ship the .addins file within the nuget package by adding the following lines to the .csproj file of the extension project.
<ItemGroup>
<Content Include="file.addins">
<Pack>true</Pack>
</Content>
</ItemGroup>
If I add the .addins file to the target project by hand, the engine extension starts working.
How can a nunit engine extension be shipped as a nuget package without any adjustments by hand?
Im using NUnit(3.13.2).
Im quite new to nunit, nuget and writing questions on stack overflow. So if I'm missing something obvious here, I'm sorry.
This is one of those areas where I wish things were less complicated, unfortunately. Since extensions are found through a relative path from the NUnit engine to the package content, it depends on where both the engine and runner are located and where the package is located on your machine.
Here are some initial guidelines...
How to structure the package itself... your extension assembly itself should be in the tools directory. If there are other assemblies with it, which it references, it's best to also include a .addins file in the same directory, which lists that assembly on a single line. That way, the NUnit engine will save time by only examining the extension assembly.
A NuGet extension package will automatically be found by the engine if the runner has been installed as a nuget package as well. This works no matter how the packages are installed on your machine, i.e. using packages.config or in a nuget cache, provided both packages were installed the same way. (That proviso is a real gotcha and it may be that a future version of the engine needs to actually understand nuget.) See the addins file provided with the the NUnit 3 console runner as an example of why this works.
The same thing is true if both the runner and the extension are installed as chocolatey packages, because they are both in the chocolatey cache. If you do provide one (which I recomend) it has to be a "native" package - one that includes the actual binaries. A chocolatey package that merely invokes the nuget package will not work. See the source for any of the NUnit-provided extensions for an example of how this this is done.
If the executing copy of the engine (usually in the same directory as the runner) is anywhere else, there is no automatic way for the extension to be found. This includes the case where you are building a runner yourself and want the extension to be available while you are developing. In that case, you need to fully understand how the engine finds extensions (see the docs) and manually create an addins file (next to any that was distributed with the engine) containing the proper relative path.
This is especially complicated if you are developing an extension for general release. Then you have to deal with various runners installed in different ways by different people. OTOH, if you are doing this for internal use in your company, you may only need to deal with one of them. If you add more specifics about your goal to the question, I'll edit this with some more specific suggestions.
I have created a nuget package containing a DLL that I want to share with multiple applications. I want to add this package to applications without setting a reference to the DLL. I am using dependency injection to load this DLL or a test DLL at run-time.
By default, nuget automatically sets a reference to all DLLs contained lib during installation.
Is there any way to configure the nuget package to not set a reference to the DLL when it is installed into my project?
Explicit assembly references. Although if your dll is loaded entirely at runtime (using MEF or Assembly.Load or something similar), then the build system might not copy the dll to the project's output directory. Note these docs are only correct for packages.config projects. I have a PR to improve the docs to explain how to do the equivalent thing for PackageReference.
I have a solution in Visual Studio 2013 with more C# project files that have source code in common but are targeting for different platforms (.Net, WinRT, .Net Micro Framework and so on).
All the csproj files are under the same directory.
These projects use a Nuget package that is available for all the above platforms itself.
If I add this Nuget package for one of the project (ex. .Net), the package.config file is created and inside has reference to that target (ex. .Net). The package is downloaded in the packages folder.
If I try to add the same package but for a different target to another project in the solution, the UI tells me that the package is already installed. It's true because a package.config file is already there but I'd like to have the same package for a different target.
So my question is the following : how can I add the same Nuget package to all different projects but with different targets ?
Thanks,
Paolo
Unfortunately, I don't think NuGet supports your scenario.
NuGet expects the packages.config file to be in the same folder as the .csproj file. There should be a 1-to-1 relation between these files. You should create a separate folder for each project rather than keep all .csproj files in the same folder.
If you want to share code across multiple projects, the easiest way is to use the new Shared Project support in Visual Studio. Normally this only applies to Universal Projects, but there is an extension[1] that you can install that enables Shared Projects for all project types.
Simply create a new Shared Project. Add all you common code to it. Then in your platform specific projects, you can simply Add Shared Project Reference.
Since each project is now independent, NuGet will add the appropriate package.
Hope this helps. Good luck!
[1] Shared Project Reference Manager https://visualstudiogallery.msdn.microsoft.com/315c13a7-2787-4f57-bdf7-adae6ed54450
I have created a NuGet gallery in my company.
I want to create and publish a solution level NuGet package.
Everyone who will install the package will not get a dll but an entire project added to his/her visual studio solution.
Just like adding an existing project, the user will get a project with source code classes and everything is ready to use.
Just build it and use it.
I know it's possible, but couldn't find any documentation.
Anyone?
It is possible to add any files (not only .dll) and even directory structures to a NuGet package, so in theory you could store all files belonging to a project in a package and publish that. However, it is only possible to install NuGet packages into an existing project, meaning that you won't be able to add the packaged files as new project to any solution. In addition, the contained files will be put to the solution's packages folder, not to a solution or project folder.
As an alternative, consider creating a Template project instead of a NuGet package, as explained in How to: Create Project Templates and my blog post Creating template projects. This will result in a .vsix file that any developer can install as Visual Studio Add-In, the templated project will then appear in Visual Studio's File -> New -> Project... dialog as new project type and can be added to any solution.
Similar to your NuGet gallery, it is also possible to create a private Visual Studio Gallery to share such Add-Ins within, for example, a company, as explained in this MSDN article.
I've added several Nuget packages to my multi-project solution with no issues. However, when I add this package -- ews.x64 (Exchange Web Services API) -- Nuget does not allow me to add it to any particular project.
The packages subfolder is created normally:
D:\TFSSource\Exchange\Utilities\Src\ExchangePurge\packages\EWS.x64.1.2
but when you attempt to manage the solution's installed packages, the "Manage Nuget Packages" dialog only offers an Uninstall button for this particular package. All the other packages have the Manage button allowing them to be added to the individual projects.
Also interesting is the fact that this package appears in a packages.config file under a newly created solution folder called .nuget? Any ideas what might be causing this?
Looks like this is a solution-level package, a package that doesn't have project specific content or libraries. The package is probably installed correctly and available to all projects at once.
source:NuGet FAQ