I am working on Portable Class Library(PCL) and trying to achieve MEF in that. I used System.Composition from Nuget. When i build and package for vsix (Extension for Visual Studio) it doesn't package and place those dll's to extension folder
(C:\Users\UserName\AppData\Local\Microsoft\VisualStudio\14.0Exp\Extensions\ExtensionName\AppName\versionofYourApp). When i manually place those library in this folder it works fine. Can some one suggest a good solution to this problem. I am writing it for Roslyn Analyzers and creating a nuget package. Again i am facing the same issue, even if i am packaging those library together.
Set Copy Local to true in the VSIX's reference to the MEF DLLs.
I found a solution, thought of sharing. You are welcome to correct and suggest. For Vsix extension i added those library as an asset(VisualStudio.Assembly) from local.
And for packages, Assembly.Load("AssemblyName") was trying to load library from all possible locations like " C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies" and many. So i placed it there and it was getting loaded. I know this is not the best solution. You are most welcome to suggest.
Related
I am trying to build a VSIX extension that is using some NuGet packages.
When running the project I get an exception "Could not load file or assembly or its dependencies". I've included the package dlls themselves and they get copied over, but I suspect they're missing one of the numerous dependencies. But I don't know which ones.
I've found many old links here with similar issue and tried everything, but nothing seems to work.
Specifically I am trying to use MdXaml nuget package. It looks like it's relying on AvalonTextEdit, and that itself is relying on bunch of other stuff.
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 a .NET Standard 2.0 class library project with installed Nuget package System.Data.SqlClient version 4.4.0 and a Windows Form .NET Framework 4.7 project that has a reference to that class library.
Installing the Nuget Package and building the solution is successful. but in runtime every time that the code reaches a method that has any thing from SqlClient assembly inside it (for example an instance from SqlConnection) it gets this error:
Could not load file or assembly 'System.Data.SqlClient,
Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified.
Considering this question, I assume the problem was also there in the last major version of the Nuget package.
Edit
I downloaded the Nuget package and unzipped it and from \ref\netstandard2.0 folder copied the System.DataSqlClient.dll manually in \bin\Debug folder of my Windows Form Project and now it works. The exact situation also happened with Microsoft.Win32.Registry package. So I was almost convinced that it's my fault and I'm doing something the wrong way, but when I tested it with System.Drawing.Primitive Package it worked perfectly without any need to copy a dll. Now I'm really confused.
I guess you may have figured it out already but hope it would help someone - wasted some time too on this.
So, in order to make everything work you would need to reference System.Data.SqlClient in Windows Form project that is referencing your .NET Standard Library
From that point everything should be working like a charm
As you already mentioned System.Data.SqlClient.dll was not in output directory.
Sounds like .NET Standard Library haven't grabbed with itself dependent library binary. There is nothing like "Copy Local" option in .NET Standard references so I don't see any way to check or set this behavior too
I had same problem.
Solution for me was adding dependecy from nuget for latest System.Data.SqlClient at my .NET Standard Library project.
I had the same problem. The .NETStandard assembly was added as a reference to my WPF project. I needed to make changes in the .csproj of the WPF project.
The solution mentioned in https://github.com/dotnet/sdk/issues/901 fixes it.
Steps:
Edit your core .csproj file in notepad.
Add the below two lines in each that you find in it.
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
Clean and rebuild your solution.
I had a similar problem, bindingRedirect helped in my case:
<bindingRedirect oldVersion="0.0.0.0-4.4.0.0" newVersion="4.4.0.0"/>
We are migrating over to using packages and NuGet for managing our dependencies on 3rd party components. This works well when referencing packages from within Visual Studio or building on the build server via msbuild.
However there are a number of files that we would like to access in our build scripts and installers. Previously these would be in source control with a well known path, now as the version of the package that we are consuming changes so the path to the package and hence the files is changing.
Is there a simple way I can get the path to a given package? The best solution I currently have is to search for all packages.config files and extract the package version from them.
Examples of the files that we need to access are
The NUnit console executable from the NUnit.Runners package for running unit tests.
License files from various packages that we redistribute with our installer.
Using the packages.config file is a pretty good solution. NuGet itself uses two approaches:
Reading the package information from the packages.config and using that to resolve to the packages path.
Enumerating all the directories in the packages directory.
You could use NuGet.Core to do either of the above if you do not want to write the code yourself. The classes that can be used are the DefaultPackagePathResolver, the PackageReferenceFile and LocalPackageRepository or SharedPackageRepository.
One problem with the second approach is that sometimes NuGet may occasionally leave behind NuGet packages that are not necessarily referenced by a project. In that case looking at the package directories may give you the incorrect information.
The only other approach I can think of might be to read the project files looking for the assembly references. Although that would not work for a solution level package such as NUnit.Runners.
I created an NPAPI plugin. It uses two other Dlls.
I need to pack those Dll files along with Plugin dll as Extension.
How can I do that? So that I can Place that dll to any folder and register it.
Is there any way to do this?
Sorry if its a duplicate.
thanks in advance.
If you pack it as an extension, you just put the two DLLs you need in the same directory in the extension as the plugin DLL.
Note that some browsers the search path may have difficulties finding those DLLs; if you find this to be the case you could try DELAYLOAD linking those DLLs and use SetDllDirectory to add the plugin dll directory to the path.