I have a legacy project (written and compiled in .Net 2.0), it is huge, and lots of other projects are referencing that. It is planned to decommission it, but it will take some time. I'd like to introduce new version of that project where any new functionalities will be put and .NET 4.5.1 will be introduced.
I want to keep all the old functionality of old project to be accessible from the new Project2 and only. Without converting old project from .Net 2.0, without any need to reference Project1 dll when Project2 is already referenced.
I am aware that projects compiled for .NET lower than 4.5.1 won't be able to reference Project2 (because of higher .net incompatibility), Project2 is a part of new world created to abandon the legacy code.
How can I achieve that? Currently I am inheriting all public classes (~150 of them), it works but still I need to reference dll of the old project.
You could create an intermediary assembly which references your old assembly and it's newer replacement. Then from any future projects, it could just reference the intermediary assembly. That would allow you to work at your own pace to slowly replace functionality in the old assembly with functionality in the new assembly while not affecting higher-level code that references it.
How about this:
Create a new solution
Add a project to this solution and set its .Net version to 2 (project 1)
Add another project to this solution and set its .Net version to 4.5 (project 2)
Yo can add the classes (source code files) from project 1 into project 2 by adding 'Existing Items' and making sure that you add them as link (click on the down arrow on the 'Add'button in the open file dialog). Or you could just copy the code files into project 2 (duplicating the code)
Each project will have a different DLL name and can be in different version
Related
We are upgrading our project to .NET 6 from .NET Framework 4.5. We have a windows form application. Many of windows form commands has been depriciated in .NET 6. So to tackle this, I changed one of the Windows Forms project in the solution from:
<PropertyGroup>
<TargetFramework>net6.0-windows</TargetFramework>
</PropertyGroup>
to
<PropertyGroup>
<TargetFrameworks>net45;net6.0-windows</TargetFrameworks>
</PropertyGroup>
Now after changing this, I get the below error:
Project <another_project> targets 'net6.0-windows'. It cannot be referenced by a project that targets '.NETFramework,Version=v4.7.2'.
I understand why another_project is throwing this error message which is because the another_project is referenced in this Windows Form project and another_project's TargetFramework is .NET 6. So, I can change the TargetFramework for another_project to include .NET 4.5 as well.
But my question is, if I change this TargetFramework to TargetFrameworks and add multiple Framework there, does that mean my project is not upgrading to .NET 6 completely. Since it's using .net45 to complie/build in those cases, where it's failing to build in .NET 6. How does TargetFrameworks work??
I found the below link also, TargetFramework vs. TargetFrameworks (plural). But was not much helpful to understand this.
I'm assuming that you've upgraded your project files to SDK-style.
<TargetFrameworks>net45;net6.0-windows</TargetFrameworks> will effectively build your project twice - once for .NET 6.0 and once for .NET Framework 4.5.
(I'm not sure why your .NET Framework project is still targeting .NET 4.5 - I would have thought you should have retargeted it to 4.8 a long time ago...)
The output folders for these two targets will be:
For the DEBUG build:
\bin\Debug\net6.0-windows
\bin\Debug\net48
For the RELEASE build:
\bin\Release\net6.0-windows
\bin\Release\net48
Now if you want to reference one of those assemblies in another project, you're going to need to decide which to use, depending on the target framework for the dependent project.
In your case, it seems that you should be referencing the one in the "net6.0-windows" folder, so you should change your other project to reference that.
However, if you want the dependent project to ALSO be multi-targeted, you will need to change the hint path in the dependent project to use a compile variable to select the correct one.
For example, suppose your multi-targeted dependent project currently references a DLL using the following hint path:
<Reference Include="YourLibraryName">
path to referenced dll\bin\debug\net45\YourLibrary.dll
</Reference>
(Where "path to referenced dll" is whatever path is needed to locate the library.)
Clearly that will only reference the DEBUG Net 4.5 version of the library. You want it to reference the correct debug or release version and the correct .Net 4.5 or .Net 6.0 version. To do that, you can change the hint path to:
<path to referenced dll>\bin\$(Configuration)\$(TargetFramework)\YourLibrary.dll
At build time, $(Configuration) is replaced with the correct DEBUG or RELEASE string, depending on whether you're building DEBUG or RELEASE.
Similarly, the $(TargetFramework) will be replaced with the current build target, taken from the <TargetFrameworks>net45;net6.0-windows</TargetFrameworks> setting - either "net45" or "net6.0-windows".
Doing this will cause the correct DLL to be chosen from your multi-targeted project on which this project depends.
Note that this only applies to references using HintPath as above. If you're using project references, things would be different.
Also note that it's also possible (and maybe better) to create a NuGet package which will handle the dependencies etc properly, but that's a whole different story.
TargetFrameworks is used to build same project to multiple frameworks (so you have binary for each of them in output). It's usually used by libraries so they can be consumed by app targeted for different frameworks or, much less frequently, by apps, so they could be run on different machines.
I guess neither of theses is your cases. You just need to rework your app so it uses only features available in .NET Core.
Since you have added both net45 and net6.0-windows to your project it means that it should be compliable for both frameworks (i.e. it will be compiled twice, for each of the target frameworks), but you are trying to add reference to net6.0 project, which can't be used from net45. You need to either upgrade both to net6.0 only, or add net45 to the another_project.
Though usually it is another way around (compared to what you are trying to do), you use multitargeting for library projects (i.e. another_project in this case if I understand correctly) and keep one version for the executables (i.e. WinForms project should keep it's version).
I built a class library as a NuGet package to be used in another C# project. When I built the class library, I followed a tutorial that suggested targeting .NET Standard 2.0.
I installed the package into the other project and it builds fine. However, I've noticed that the output folder contains several other 'System.' dlls (ie. System.AppContext.dll).
In the past, when I've built a class library for C++, I did not get the dependent dlls copied to the output folder. I had assumed that building a C# class library would act the same way. For C++, those dependent dlls are resolved at runtime by the C++ redistributable dlls. I thought the same would be true in that C# would resolve them through the installed framework.
So, I'm a bit confused as to why the extra dlls are present in the output folder. Is it because I targeted .NET Standard 2.0? Do I need to ship the extra dlls with my application?
I have a .NET framework WPF project that references a .net standard library that I wrote. This library references io.ports.dll
I found that there is a problem with .net framework referencing .net standard projects and that it would not copy the io.ports.dll to the output folder. The solution here was to add the dependency to my WPF project also which solved the problem.
However I noticed that the two projects reference the io.ports.dll from different locations.
The WPF project references from
project location\packages\System.IO.Ports.4.5.0\lib\net461\System.IO.Ports.dll
The .net standard library io.ports.dll location is
C:\users\.nuget\packages\system.io.ports\4.5.0
The DLLs have different sizes, although they are the same version.
The problem appears when I use advanced installer to create a .msi.
It gets very confused and tries to copy both DLLs and in the end my .net standard library tries to read the wrong DLL.
Anyone have any idea how to solve this?
Pavel answered (now deleted) that it was due to my GUI project using the old packages.json. This solved the original problem. Another problem was that the io.ports dll has a dependency on Microsoft.Win32.Registry.dll which I also had to add to the GUI project.
I've added a new Class Library (Package) project to my solution. It's my first experience with a .NET Core (or whatever I'm using, still confused)
My class library contains two references: .NET Framework 4.5.1 and .NET Platform 5.4
I'm trying to import some code from a sample project that uses IPrincipal. For some reason it's saying that it doesn't exist on namespace "System.Security" altohugh I can get it trough intellisense.
What's wrong with my project settings?
The new feature of .NET Core and Class Library (Package) is that it targets multiple platform and will compile into multiple assemblies which get automatically packaged into a nuget package.
When your class library targets multiple targets, it will compile to all of them. So if a certain library is only available on full .NET framework but not on .NET Core or other target framework, then you may receive intellisense if your editor is set to .NET 4.5. More information can be found in my other recent answer.
You can switch back and forth with the pull down menu on top left of the coding window, show in the screenshot below.
If you do not want to target a certain framework, you have to remove it's moniker from the project.json file or use preprocessor directives to write platform specific code or libraries/replacements.
.NET Core is heavily modularized and most of only the core modules are referenced in the default project and if you need additional one you need to reference them within the dotnet5.x section.
Basically you have multiple places with "dependencies" in your project.json, a global one where you can add dependencies which are available on all targeted frameworks and one within each "frameworks" section for each of the targets only.
Though the other answer covers some basic concepts, it would require some attention on which classes are available and which are not.
Microsoft temporarily host a web site at http://packagesearch.azurewebsites.net to assist.
If you can find a suitable package for RC1 from there, then you can add it to your project.json file. If not, you will have to conditional compile it to a desktop profile or use other alternatives.
Environment: Visual Studio 2013, C#, ASP.NET MVC
Question: For the projects that I create in Visual Studio that use C#, I would like to give others one compiled DLL as opposed to them having to add any extra DLL references themselves.
Example:
I have a project that is used for web services:
MyProjectWebServices.dll <-- this is what I would just like to hand out
Some3rdParty.dll
Another.dll
SomethingElse.dll
So, for the above 4 libraries that other projects need to reference as well since my original distributable library (MyProjectWebServices.dll) references them, is there a way to bundle the bottom 3 into just the first one?