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.
Related
After searching quite a bit, I seem to be unable to find an answer to my problem. Usually, I find that means it is a non existent or incorrect approach, but I think it worth it to have an answer floating around on the internet nonetheless.
Essentially, we have 4 applications referencing 5 different "source" projects. So the scenario is, when we add a 5th application (for example), we will need to create project references to the other 5 different projects, as the application requires their output.
Its not a difficult task because the amount of projects is small, but it got us thinking. What if you could create a single project, maybe called Libs or something, reference all 5 projects in that project, and then the applications must only reference Libs. The idea seems cool, but I don't know if it will work because when you create a project reference, it points to Libs single output libs.dll.
So to actually ask a question, is this possible, and if so, how can it be done? Currently, having Libs reference the other "source" projects, and then having the applications reference the Lib project does not work, as it says there are missing assemblies.
And just to go over how this was created. The 5 source projects reside in a couple different solutions, so the only tedious part of this approach is "add existing project" at the initial start of the application's solution.
The way we manage this kind of thing in my organisation is to make a NuGet package for each of these shared "source" projects (e.g. in our case we have an error logging library, an XML utils library, a bespoke HTTP client, and others). These are published to our private NuGet feed URL (hosted on Azure DevOps, but you can just use a standard Windows fileshare if necessary) for our developers to use in their applications.
This has some clear advantages over your approach:
1) Dependencies - this seems most relevant to your question. If the project you built the NuGet package from itself depends on any other NuGet packages (either publicly available ones, or others from our private feed) then when someone installs that package in their project it will automatically install all the other packages it depends on.
So in your case you could create a shell "libs" package which doesn't deliver any content itself, but has dependencies on all your other packages, causing them to be installed automatically. In our case we have several cases of dependency (e.g. a "base" error logging package which is relied on by error handling modules which are tailored to different app types, e.g. MVC, Web API, Windows Services), and it works very well.
2) Updates and maintenance. In your scenario if you make a breaking change to one of your "source" projects, then, because you have a direct project reference declared in Visual Studio, any project which references the source one will have to make related changes to cope with the updates to the source project, before you can re-compile it and do whatever feature changes you're trying to achieve. This could be a pain, and be an untimely problem, especially in the case of major updates. However if instead you install a NuGet package containing that functionality, the developer of the application can choose if and when to install an updated version of the package.
There are other minor benefits as well which I won't go into, but there are some very good reasons why almost all major programming languages now provide similar "package" and "feed" functionality as a way of managing dependency on external projects and libraries. Your approach is, I feel, outdated and naive, resulting in the issue you've described and the potential for other irritations as well.
I am creating a crossPlatform Project. I want to add the sqlite-net and the sqlite-net extension to my shared Project, it seems that i can't add nuget packages to my shared project. is there a way to add it or is ther another way to use sqlite extension in the shared project without importing the nuget package
This is the answer:
https://forums.xamarin.com/discussion/70403/add-nuget-packages-is-disabled
When you create a Forms app, the template will ask you if you want to
use a Shared project or a Portable Class Library for your shared code.
you most likely chose Shared project which is NOT a real project in
that it doesn't compile to a DLL like other project types. therefore,
you don't add nuget packages to a Shared project. the Shared project
uses the nuget packages added to the iOS and Android projects.
think of a Shared project as a collection of source code that
automatically gets transparently copied to each of the real projects
that use it as if that shared source code was physically part of the
real projects.
so if your shared code doesn't compile due to a missing nuget than you
must add that nuget to both of your iOS and Android real projects.
I would like to know how I can share c# source codes between two (or more) .NET Core projects (commandline projects!).
As far as I understand, I can not link to source files in different directories in xproj/project.json based projects. I noticed that it now seems to be recommended to create nuget packages for everything. But is it really necessary for me to setup a private repository and create a nuget package only to be able to share some common source units?
VS2015 contains a template for .NET Core library which may be suitable for building a shared lib. Is it possible to link this lib to a project without a nuget package?
.NET Core Library is an excellent solution for you.
Do it the same way as in standard C# solution - just create the project and reference this project or add a reference to DLL file.
You don't need to use a Nuget, for your own purpose. Nuget packages could be useful to distribute your dll outside.
Clarification:
I miss one point - I'm using VS2015, but I have included Class Library project in my solution, and I'm referencing by project, not by DLL file, and this works fine in ASP.Net Core.
I also have a different project, where referencing DLL file directly working fine, but this is the previous version of ASP.NET app (not Core) - seems NET Core doesn't support this way like as the previous version (yet?).
Sorry for confusing you, sometimes it's too many technologies ;)
So could you just include ClassLibrary project into solution with your project and refer it as a project?
I have achieved this by using source control to branch from my commonly used projects in each new solution, and again merging back to the master branch if I make any changes.
Alternatively, baring in mind that NuGet is only an archived collection of files, you could keep this NuGet package locally, or even create a Template for Visual Studio that has the common libraries by default.
There are a wide range of possibilities that are down to your preference, and current environment state (I.E: Able to setup Source Control, or a package repository).
I'm currently working on a redesign of multiple different projects. One thing I noticed is 2 sub projects that are included in their own versions in each and every of the main projects. These sub projects are in essence nothing more than projects that get compiled into dlls.
Now I know that I could extract them and compile them and then include the dll into the appropriate projects where they are used. The only problem with this method is that if the source code of those sub projects changes and thus the dlls I would have to manually copy them into each and every main project. As it
has to be done manually this means in essence that I could overlook to update it
for single projects which is not ideal.
So I'm wondering now if there is any easy way to handle this so that I can update these sub projects (or extracted projects) and then automatically have the updated version available for each of the main projects when they get compiled?
(To make it a bit clearer I'm wondering if there is some Visual studion solution there that allows to link these extracted projects in a way so that I automatically always use the latest version of them in my main projects)
You can easily reference same project in multiple solutions.
Right click on solution -> Add Existing Project... and select your project.
In other project you can easily add reference to your core project by right clicking on project, selecting Add Reference and then selecting project instead of dll. Any changes to core project will reflect in every solution that references it (and its dlls).
Yes you can add a common project to more than one solutions easily. Follow the steps:
RightClick on Solution > Add > Existing Project... will let you add projects to your current solution. . This lets you include the same project in multiple solutions.
Then you can add a reference to the common code from other projects by adding a project reference to that class library. The advantage of having a project reference as opposed to a binary/assembly reference is that if you change your build configuration to debug, release, custom, etc, the common class library project will be built based on that configuration as well.
I have a such solution hierarchy:
Solution "App"
project App
project Lib
For example, if i want to use somedll.dll in App and in Lib project, i must add references to both projects, but as i understand there must be a way to add .dll only to Lib project, so classes from it would be reachable in App project. Is there a way to do it? Thank you.
If you have, let say, a logging library that will be used along the whole project, then that library must be referenced everywhere it's members are called.