Okay, this is (or at least should be) a stupid question: How do I add a reference to a system assembly in .NET Core projects?
I have a .NET Core class library. If I right click on Dependencies, there is still a Add Reference... command, but it only allows me to add references to my other projects. There is now an SDK section, but right clicking there provides no option to add new references.
This was so straight forward before. I don't understand why this has changed or how I now add a reference to something like Microsoft.Win32.Registry. (My understanding is I need a NuGet package for this assembly, but my question still stands about adding system references.)
Even if your system contains this assembly it does not gurantee that other systems also contain it. .Net Core is about cross platform so I do not think there is this assembly in Linux system. So you should distribute not only your code but some of "system" dll as well. And it is easier to update only one nuget package for adding new functionality, bug-fixing, etc than update all framework.
Related
I have a Solution with .NET Framework Project A which builds a winforms application containing a class, MyPlayer which requires LibVLCSharp. In order for the application to build and run correctly I had to add the following Nuget packages:
LibVLCSharp
LibVLCSharp.WinForms
VideoLAN.LibVLC.Windows
Now I want to move class MyPlayer to a separate .NET Standard class library, Project B, to separate out function from UI and so that it can be used by multiple other projects targeted to different platforms. In order for B to compile I only had to add the LibVLCSharp Nuget package. Then I set B as a Reference for A.
Obviously, Project A is going to require the other two Nuget packages somehow, but I am unsure to which project it is most appropriate to add them. What makes the most sense in this situation? Or is there really only one way it would work?
that's a good question, and I don't know if it is properly documented on LibVLCSharp.
Short Answer:
LibVLC must always be referenced on the executable project (A)
WinForms isn't compatible with .net standard, so you can't reference it in B if you keep using netstandard.
LibVLCSharp can be moved "up" in project B if you need it there.
Long answer:
Let's see the packages in detail:
VideoLAN.LibVLC.Windows : This package contains the required dlls files that are required to make libvlc work on Windows. It also contains msbuild files that are used to copy the DLLs to the output directory of your project. You need those files in your application, so you need to reference this package in A. (They won't be transitively copied by a Project reference)
LibVLCSharp.WinForms : As stated here, this package only support .NET framework 4.0 and above, and .net core 3.0 and above. You will not be able to add this package in B, unless you replace your netstandard constraint and use multi-targetting instead. It will only work where WinForms is available.
LibVLCSharp can be referenced in project B without any issue. Since you're using .net standard, chances are you are also using the "SDK-style" csproj format and PackageReference. The dependency will then transitively be available in project A without adding it there.
If your point was having a player Form available in both .net framework and .net core, I'd recommend that you use multi targetting, by putting this in your B project:
<TargetFrameworks>net40;netcoreapp3.0</TargetFrameworks>
otherwise, if it's just for sharing non-ui code, you don't need the LibVLCSharp.WinForms dependency in B
I've been creating my first for .NET Core projects. (In this case, just a console application.) And I've noticed that when I right click on Dependencies and select Add Reference, the dialog that appears no longer includes an Assemblies section.
In previous versions, this section would list all the Microsoft assemblies and include some additional information for each assembly. Now, my only option is to click the Browse button and see if I can find the folder that contains the correct version of the assembly I'm after.
Since this seems to be a loss of some basic functionality, I can't help but think I'm missing something here. Can anyone say why this section was removed in .NET Core? Can anyone say what is now the preferred way to add additional Microsoft assemblies to a project?
I'm not quite sure, but I guess it should be related to the modularity of the framework. Previously in .NET Framework you just downloaded the entire framework and has access to all the assemblies available inside the framework. That's not the case in .Net Core, because now the framework is way more modular, and everything is a Nuget Package. In case you want to add a reference to another assembly you just have to download the nuget package that contains the assembly you're looking for.
I'm working on a project, to which I would like to add Prometheus metrics exporting. There's a pretty great library for it over at NuGet that I've used. The new version (2.0.x, prerelease), however, is supposedly build for .NET Standard. That's fine, but my current project is built for the .NET Framework on Windows. When I add this NuGet package, however, I get over 100 assemblies added to the output of my project, including many that I don't think are related.
I added an issue for this to the project, but the project maintainer came to the conclusion that this is normal. I don't agree, however, and I'd like to know if there is a specific suggestion I can make to improve the situation.
What should prometheus-net change to avoid adding all these assemblies to the output of my project?
This is a flaw/bug/unfortunate side effect of the current .NET Standard 2.0 build situation. When a .NET Framework before 4.7.1 is targeted, the system cannot be sure that all the dependencies exist, so it copies all of these extra assemblies to the output.
4.7.1 has everything that .NET Standard 2.0 needs, so they will not be included if that framework is targeted (though, things might break if an earlier framework is used at runtime).
There is information (and a workaround that seems to work for me) at https://github.com/dotnet/standard/issues/415#issuecomment-314288712
I wanted to use two different version same library (OpenCVSharp 2.x and OpenCVSharp 3.x).
I downloaded those two packages both to the separate project (let's call it OCV2Wrapper and OCV3Wrapper) and reference both wrappers in my project. I had to renamed libraries from one package (2.x) and reference them manual because: Can we add 2 different versions of same package in NuGet. I read about external aliases and I used external alias in one of the wrappers (2.x in my case).
But I have some major problems:
My renamed libraries are not copied to the launch project build (that one which reference both wrappers), but is in build of the 2.x wrapper
It doesn't work because yet it says it cannot find a type from my 2.x wrapper even when I manually copy my renamed libraries from 2.x wrapper.
What is the correct approach for this scenario in C#?
I want to use both wrappers in solution because the 2.x version contains algorithms (SIFT and SURF) and 3.x version contains algorithms (Kaze and AKaze).
I can live that with both packages coming from somewhere other than NuGet, but I prefer that 3.x comes from NuGet and the 2.x version is manually configured.
As already stated, there is nothing wrong with referencing 2 different versions of a NuGet package, as long as it's in different Visual Studio Projects that those references are made.
But this is also where the easy part ends, but I think there are a few options left. Depending on your needs, I see the following options.
Create a post build step which registers the multi-versioned assemblies into the GAC. As long as each assembly have different assembly version, the CLR will pick up the right assembly from the GAC when needed.
Create a post build step which copies the different assemblies into a subfolder of your application bin folder like bin/package-v1 and bin/package-v2. Then you can, in your application, override the AssemblyResolve event as described here: https://msdn.microsoft.com/en-us/library/ff527268(v=vs.110).aspx. This will make it possible for you to load the assembly in the right version at the time of need.
If you don't want to play around with AssemblyResolve, then you can also modify your web/app.config to do assembly redirect/probing as described here: https://msdn.microsoft.com/en-us/library/4191fzwb(v=vs.110).aspx
Hope this helps a bit, so you don't have to modify third party source code next time.
OK so, I solve this by downloading whole sourcecode for 2.X wrapper version.
Renamed its namespace to ABCDEF2 where ABCDEF was original namespace. Build my own nuget package with my own key and... publish it to our private nuget server.
This is such a lame solution but there is no other way than manually downloading the original packages and reference it directly with different filename etc and you loose nuget advantages.
This is a weird one.
I created a new Windows Service in C#, and want to re-use some of the code we created before that's in a Class Library.
The project is loaded in the solution along with the service. Both target .NET Framework 4.0 (not client profile).
I tried adding a project reference, and it worked for a short while. After working on some old code that I was rewriting, when the project compiled again, it complained that it no longer recognised the namespace for the using statement.
I've made sure to clean the solution & rebuild, but no dice. Sometimes VS can have a bad day, so I restarted VS, but this also didn't work.
I then build the DLL, and add a reference to it via 'browse', also no dice. Then I tested it on another project, but after adding it, it works instantly, so it's not the DLL.
I then checked with other libraries in the solution, but I was able to add a reference to them in the service and access their namespace without a problem.
I'm out of ideas here, anyone got an idea of what to do here?
Thanks,
Nick.
Almoast forgot: the weird thing is, that if I open up the Class view, and expand the 'References' section, the namespace/dll doesn't show up there either... it's a real conundrom...
I should pay more attention to warnings:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3253: The referenced assembly "" could not be resolved because it has a dependency on "System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client". Please remove references to assemblies not in the targeted framework or consider retargeting your project.
So, I'm a ready idiot for checking the DLL's target framework but not the Windows Service :)
The problem is my DLL uses System.Web, which is not part of the .NET 4 Client Profile framework target. Changing the Service's Target Framework to 4.0 fixed it.
If the class view doesnt show the types that should be there, the actual dll you're compliling against is not the correct version.
There could be several reasons for this
A previous compilation of the dll might still be around
The project might reference another, older, binary version of the library rather than having a project reference
Another project mgiht be referencing an old version of the dll, and have copy local set to true. When that project is compiled it overwrites the new version of the library
Make sure all projects in the solution use project references, and remove all binaries you can find.