Hello, I am a bit rusty with all the .NET stuff at the moment… hope to seek some advice here.
I want to write an external program using .NET winforms to help with creating binary game data .bytes files to be bundled into Unity TextAssets. To keep things organised, the Unity runtime and winforms program should be using the same .NET class library reference to handle the data protocol read/write and data structs.
The the winforms program (.NET Framework 4.7.2) can only reference a class library up to .NET Standard 2.0. However in Unity 2022.3.7f1, the Api Compatibility Level option only has .NET Framework and .NET Standard 2.1. Setting the option to .NET Framework works, but it makes entire Unity project target .NET Framework, which is not ideal (???).
If it makes sense at all, how can I keep every Unity related dll at .NET Standard 2.1, only the shared class library at .NET Standard 2.0, and the .NET Framework winforms program separately can use the same shared class library?
I can offer an alternative approach: put the shared scripts not in a DLL but just keep them as is in a given folder. Then you can use symlinks to import that folder in either the Unity project or the Visual Studio project, or both.
The only downside to this approach is that if you edit these files from within the Unity project (and IDE) due to the higher API level you need to be careful not to use incompatible (modern) C#/.NET features.
Why is that?
I see no reason why a .NET 4.x project could not reference another .NET 4.x library project (or DLL).
@CodeSmile Sorry, I made a typo mistake there. I meant to say “… .NET Framework 4.7.2 can only reference class library up to .NET Standard 2.0” as per this documentation
Also, I will keep in mind your suggestion as one of the options if nothing else better comes along, thanks!
So if I get this right, you can just target .NET Framework. You could dig deeper and figure out what the pros and cons for Framework vs Standard are in the context of Unity. I don’t really know, the manual doesn’t state it clearly either.
Standard may be slightly more compatible if you plan on upgrading the project over the next couple years as Unity is moving to CLR Core etc.
Alternatively, ditch WinForms and use WPF. Or make that GUI inside Unity with UI Builder.
Just coming back to update on how I resolved the issue, given my circumstances.
I normally code everything in Visual Studio Code.
But for this external .NET Winforms project, I am using Visual Studio 2022. To overcome the .NET version incompatibility, in the external tool project, I created a link to the source files in the shared library project.
I am using Windows PC.
To create the link, from Windows File Explorer, copy the folder where the source files are, then go inside Visual Studio 2022 > right click on the external tool project > in the context menu, click “Paste As Link”. This creates a symlink to the folder where the source files are.
In the linked folder, there are many files. In Visual Studio, click on the individual files and under properties > Build Action, you can set to None to ignore them. I haven’t found a way to hide them though.
Once that’s done, the source files can compile with the project as one single application.
Update Again: Part of the reason I ran into this problem in the first place is because I choose unknowing chose the wrong framework for my class libraries when I created the project in Visual Studio. I intended to choose .NET Standard 2.0, but chosen something else (which I cannot remember). After I changed the framework, there were no more complications.