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/
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 am facing a weird problem. I have multiple .net standard class projects in my solution. There is one .net standard 2.0 class library project called Messaging (.csproj) which uses ActiveMQ to push and read data from it. This project reference to Apache.NMS library. Now I have another project called Core (.csproj) which references to the Messaging project. During the constructor call of the class inside Messaging project in Core project, I get the error that System could not find Apache.NMS dll. If I add this reference in the Core project then everything works fine but I really do not understand why this is happening. With a pure .net framework thing, I never faced this issue. Separate projects with their own references and working independently.
Can anyone help with it?
I have added all references from nuget
After lot of research i found the solution of this problem. What was happening is in the bin folder of the .NET framework / standard project the dependent dll of the referenced projects were not getting copied.
Solution for .NET Framework project:
Open .csproj file and add below line in the first tag
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
Solution for .NET Standard / Core project:
Open .csproj file and add below line the first tag
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Now compile the projects and you will see all the required dll's are present in the bin folder.
Hope this help someone else who is facing the same issue.
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 am working on a Windows Service Application. I have several classes in the project and I am trying to put these classes into a ClassLibrary so I can use those classes in the Service App Project, and also in a Console Application Project, so I can run the console version and step through the code. I don't want to re-invent the wheel here...
I have created a Class Library project, and I am having trouble updating the projects in this Solution to use these classes. In fact, when I moved all my classes into the Class Library project, they are all now throwing errors saying, "System" has no member "Data"! My A$$ it doesn't! Pulling my hair out.
Obviously, I have done something wrong. I've been programming since before there WAS a Visual Studio IDE, but this is SEEMING way more complicated than it should be.
Now my Service project cannot reference my Class Library project because the library doesn't have a .dll or .exe extension? I actually have to specify this somewhere, WhereTF do I do this? Isn't this the default behavior of a ClassLibrary? OMG! I just finished an iOS application, and NEVER thought that would be EASIER than a C# app! I did this in VS2010 easily, is 2015 really different?
It should take me no more than 30 minutes to move files from one project in a solution to it's own project, and then add a reference to that new project in the old one. Giving MS a MegaMindWedgie right now..
Don't need portability with RT hardware, just want 32-bit/64-bit computer apps.
All 3 projects are using the same namespace. I can't seem to add any references to the ClassLibrary project like I can in the Service project. It's blank. The only reference available to the Class Library project is .NETStandard,Version=v1.6
HELP...
It looks like you have created .NET Core class library. You can determine this based on the extension of the project file: *.csproj has been used with classic .NET framework projects, and *.xproj was introduced for .NET Core. Most probably, you don't need a .NET Core class library. So, your problem will go away if you create .NET Framework Class Library project.
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).