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).
Related
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.
The setup: I've created a library targeting .Net Standard 2.0 in VS 2017 and this library uses NuGet to reference a 3rd party driver and manage its dependencies. So far, so good.
The next step is to create an application that uses the (shared) library, in this case a console app targeting .Net Core. I can, of course, add a reference to the DLL(s) that form the shared library. That compiles but doesn't run because the 3rd party stuff is missing. I could of course just copy all required DLLs to the application but for obvious reasons I'd rather use NuGet.
I'm not very experienced with NuGet, never used it in this constellation and having read articles like NuGet cross-project dependency I'm getting the impression I need to fiddle with the application's project file in order to get the library in a complete form but surely that can't be the way forward.
So my question is - is the problem on the side of the library, i.e. do I need to build or export in a particular way, or on the side of the application which, IMHO, shouldn't need to know that level of detail about some library it consumes.
Any help much appreciated!
I'm sharing a large, complicated library this way with several other solutions.
First, set up your library. Right click on the library's project name and choose Properties. About halfway down you'll see a tab labeled Packages. You can use that to auto-generate the NuGet package every time you rebuild the project. Just increment the version number. I use four position version numbering -- the first three are semver-style (major release, minor release, patch release), and the fourth one I increment manually for each new build.
I recommend creating a folder on your drive or network specifically for your local NuGet packages. You can create folders under that for each project. Then you point your debug and release build output to that project folder, and the NuGet package will be generated there, too.
Finally, back in Visual Studio, go to Tools -> Options -> NuGet Package Manager -> Package Sources and add that top-level folder as a package source.
From there it's simple -- open your NuGet dependencies in your consuming app. There's a drop-down at the top right where you can choose the package source. It will automatically search all the child folders and find whatever packages you've created. Now when you tweak your library, it's just a single click to update the client apps.
Could not find an answer to my doubts and hopefully somebody can clarify.
I Have created a dummy solution with
1 class library(.net framework)
1 .net core library
Tried to reference either way but I cant,they are not compatible,fine makes sense.
Now my question
I have a utility class library(.net framework)with extensions,helpers etc...
that is used by winforms-wpf-asp.net mvc 4,5 apps now with the event of .net core it looks to me that I cannot use this library anymore unless I port it to .net core,which then i cannot use with my other apps.
What is the correct approach?
Am i missing the obvious?
Sharing code between a normal .NET library and a Core project did not work for me via simply using a Shared project, because I could not reference it from the Core project.
However, with a little trick I could make it work.
Let me explain with this folder/file structure:
[ProjectName] // Root of Core project
project.json
[ProjectName].xproj
Shared // Root of Shared project
[ProjectName].Shared.projitems
[ProjectName].Shared.shproj
// -- Source files here --
Net // Root of .NET project
[ProjectName].csproj
Properties
AssemblyInfo.cs // For both Core and .NET project
// NO source files here
So, you will need 3 projects, of course: a Core project, a normal .NET project, and a Shared project.
The Shared project has all the source files.
The .NET project references the Shared project, so it also has those files.
The Core project sees all the files the Shared project has, so it also has the same files.
That's it. You now can have common source code files for the .NET and the Core project.
A few notes:
Do NOT ever put the .shroj and the .csproj into the same folder. For me, it totally turned off intellisense in VS (2015). This information costed a lot of pain for me...
You can use #if -s to fine tune the common code
You can also use NuGet 2 in the .NET project with the above folder structure.
Note, that if you'd put the (NuGet 2) packages.config into the same folder where the (NuGet 3) project.json is located, the latter would totally overwrite the earlier.
You could try to use a shared library project. It compiles against the platform of the referencing application/library, so to speak. That gives you the ability to create class libraries targeting different platforms without the need to duplicate any code, but it may require some #if...
https://blogs.msdn.microsoft.com/dotnet/2014/04/21/sharing-code-across-platforms/
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.
I'm writing an application in .Net 3.5.
I have 3 projects in the solution so far. When adding the references to the other projects from my main project, the intellisense manages to find the classes from the other project's dlls but at compile time it seems to be "loosing" the reference.
This might be because I initially created the project with target framework .Net 4.0. However since I needed to use the ASP.NET web services I had to downgrade to 3.5.
Any help will be greatly appreciated.
The referrenced projects must be Copy Local : True
Referrence -> Properites ->Copy Local : True
Batch clean all projects in your solution, make sure all the projects in your dependency graph target the .NET 3.5 framework. Check the reference's HintPath in your .csproj file (open with text editor) for references to external DLLs and make sure they're all <=3.5.
However since I needed to use the ASP.NET web services I had to downgrade to 3.5.
There are also several different web service projects in .NET 4. I don't quite understand this move.
You have project references, intellisense sees your referenced classes but when compiling, the compiler seems not to find the referenced assemblies.
I see two possible reasons for this behaviour:
Your main project references a lower version of the .NET framework than your library projects (this is the most likely cause).
Your library projects won't get built at all / or in the wrong order (check the settings in the configuration manager. Open it with a right click on your solution in the solition explorer).