My test scenario using "PackageReference" mode:
Project A reference project B.
Project B use third party library installed via packagemanager.
The Third party library depends on other third party library (tpl2 for brevity).
I try to use tpl2 from A, does not work (Ok A does not reference tpl2).
But if i install at least one package on A (es. tpl3) then i can also use tpl2 from A without reference it.
I don't understand how this is possible, any clarification?
Usually, if project B is introduced into project A and project B uses the third-party library tpl2, then project A can call the third-party library tpl2 at runtime. But there are two exceptions:
If the third-party library used in project B is used as non-public (internal) or private (private) members, then A project will not be able to call these members, because they will not be exposed in the public API of A project.
In addition, if the third-party library used in project B depends on other third-party libraries that do not exist in project A, then project A may have a missing dependency error when compiling. In this case, project A needs to install and reference all third-party libraries and their dependencies that project B depends on in order to compile and run successfully.
In both cases, the advantages of Visual Studio are very prominent. In a nutshell, when you install tpl3 in project A, it triggers Visual Studio's mechanism for automatically importing package dependencies, which brings in all missing transitive dependencies, including tpl2, and makes them available to project A.
Of course, I can only make these answers because of the limited information you provided. If you have more ideas please speak up, but you need to provide more complete information.
Related
Main Goal: I want to create a library with fewer dependencies as possible.
The Problem:
I have a .Net Standard library (a.dll) that references a NuGet package (package) for internal usages.
I tried to achieve the following behavior when a user referencing a.dll:
The user will not have any access to the package classes and methods.
The user will be able to reference a different version of the package and both versions will be loaded to the process.
How can I achieve this behavior?
Possible Solution: Copy the package code and change the assembly name and all the modifier access to internal. Big disadvantage: very difficult to maintain.
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 want to create a C# library HighLevel.dll which also references another library LowLevel.dll with Visual Studio. Both libraries are separate projects in separate repositories. When I add the LowLevel.dll as a reference to the HighLevel.dll project I actually need the compiled LowLevel.dll assembly. That also means whoever clones the HighLevel library project needs the LowLevel.dll in place.
Is it possible to add a reference whithout actually having the target LowLevel.dll in place?
If this has something to do with loading a libary at runtime how can this be done?
It sounds like you want to create a nuget package, that references other nuget packages. When someone installs your package, the other nuget packages are automatically pulled in too.
I have just learned and created a shared project in visual studio 2017. I have noticed that the shared project did not have the "Reference" to refer to other resources (other projects, class library, …). I even take a look at the .shproj file and saw that it only Import the class I have created inside the shared project.
My problem is that if I want to create an add-in app, I need use the class library to call the necessary API that is exposed by the origin software.
How can I reference/add other project/ class library (or resources in general) to my shared project? Or is that even possible at all?
Part of my problem is also described here reference to a shared project from other shared project
But I need a more general solution. Thank you all for your help.
Long story short: shared projects don't, and realistically can't work that way.
In Visual Studio a shared project is just a container for files - source code, resources, etc - that you can add into other projects. This can be useful in some cases when you want to have the same code (and so on) in multiple projects without putting that code into a library.
Shared projects do not have references, do not have NuGet packages or anything, just the files that they contain. They don't even have the configuration data required to compile any source files they contain, and the compiler won't do much validation of the contents if the shared project isn't included into a full project of some sort.
And since the shared project doesn't have any way of specifying references or packages then you will need to add those references and packages to every project that links to the shared project. The compiler will tell you pretty quick if you miss one.
While it would be nice to have references in shared projects, it turns out to be much less simple than you might think. The same shared project can be included in projects that target different frameworks, platforms and architectures. Let's say you're building some code that will run on iOS, Mono, Windows .NET Framework and .NET Core, with specific code for each target and some shared code. If you try to add a NuGet dependency to the shared project it's going to blow up in your face on at least one of those. Same with most of the references. Add all the references you need for .NET Core and suddenly the other projects don't compile.
You need to add the reference in the project which consumes the shared project.
As an example, let's say you have "Project A" which references "Shared Project B", and you need to use Newtonsoft.Json in "Shared Project B". Since you can't add a reference to the shared project, you install the Newtonsoft Nuget package to Project A and your code in "Shared Project B" will automagically compile.
I have a C# solution in VS2010 that contains three projects. This solution has a client project (A) and a server project (B) which both build into applications. The third project (C) is where my classes that are common to both projects go (like a utility library) and this is built into a class library, which I reference in both the client and the server.
Now I want to reference a 3rd party library in my common library (C). I reference the dll and everything seems fine, I am able to use it within that project. However, when I try to use the class I created (that makes reference to the dll) in either the client or server, I get a FileNotFoundException (In regards to the 3rd party library).
I also tried to reference the 3rd party library in my client and server project as well as in the common code project, but the error is still occurring.
I also saw this question here, .NET Multiple Class Library in One Library, which suggests to me that you can reference a class within a class, so how would I go about doing it?
You need to copy the 3rd-party DLL, and all of its dependencies, to the folders containing your executables.
You can do that by setting Copy Local to true in the properties of the references.