Enable .NET 5 and .NET 4.6.1 Framework multitargeting

[VolatilePulse]

I've tested using the example application (.NET 4.6.1 Framework) as well as my project (.NET 5) and both work as expected.

Additional frameworks can more easily be targeted now.

[VolatilePulse]

Since this requires .NET 5 to compile the library now, I feel this may be the wrong approach. I'll spend some time reconsidering other viable approaches and look forward to your feedback.

[VolatilePulse]

This updated PR provides no breaking changes to the existing system. It also allows users who require targeting different frameworks to build without requiring additional modifications to the code. This project will also provide a "one-click" solution to generating a nuget package.

[VolatilePulse]

Just bumping this for visibility for leocb. I would like to discuss any concerns about this change.

If you would like assistance configuring the NuGet package for .NET 5, I'm sure I could help.

[VolatilePulse]

All components of this branch should be complete now @leocb. My last commit was purely to "embed" NuGet support into the Core project file. This will allow maintainers an easier way to create a nuget package that simultaneously targets both .NET Framework 4.6.1 and .NET 5.

I believe this PR is easy enough to adapt in the future if the need arrives. It also won't hinder other users of the repository if they don't have .NET 5 installed due to the .NET Framework 4.6.1 project file remaining intact.

The only updates to this branch will be to keep it up to date with master to ensure it's capable of being used for my other projects.

[leocb]

Hi, @orapps44 is the one in charge of this Project for now. I've been out of the loop for a while now. please review and merge if you think it's ok.

[orapps44]

Hi @VolatilePulse ,

I'm not expert at all in Framework multitargeting, I was wondering why it's needed to add MaterialSkinCore.csproj ? Can't multitargeting be added directely in MaterialSkin.csproj ?

[VolatilePulse]

@leocb

I'm sorry to hear that, but I figured as much. I assumed you were still around for consultation or approval. Thank you for how far you have brought this library based on how challenging WinForms in general is. I feel like the entire library could come crumbling down at any point with some of the changes I've made recently but I have attempted to strengthen the library as well where I can.

@orapps44

I'm not sure specifically what question you're asking here. The very first commit to this PR was me replacing the csproj file with a .NET 5 version. After submitting the PR, it dawned on me that many developers use this repo directly instead of just using the nuget package. The issue here is that it would require every one of those developers to also have the .NET 5 development pack installed, which isn't ideal or always possible. Likewise, you can only target .NET Framework from a .NET Framework project, meaning you can't build for .NET Standard, Core, or 5+.

To allow for targeting of other frameworks, the project file must be at least .NET Standard I believe. Since I specifically had a need for .NET 5, I figured that was the best place to start as it can target anything under it (and above it pending the development packs are installed). To work around the initial pitfalls on my first commit, I reverted the changes and just created a second project file.

Effectively, developers that previously relied on the .NET Framework 4.6.1 version can continue to use the original project. When they load their project and don't have .NET 5 installed, they simply choose to not load the second project file (Core) and everything will continue to work as it did previously. The Core project file allows a project maintainer, such as yourself, an easy way to create a nuget package or binaries that can work in either Framework version.

I had to make minor tweaks to the code to remove references that no longer exist in .NET 5, mostly the event handler proxies in the control wrapper classes. To ease the transition to this system, I configured most of the nuget package information so that you can just "Pack" the library and test it yourself. That single package will show that it supports 4.6.1 and 5, but effectively it will support any framework that .NET can convert it to without errors (this is why the current nuget package can't be used in .NET 5).

Finally, I'm definitely no expert in this matter and I had to do a lot of research and testing to ensure it works. I'm currently using this branch in production and have even used it with the demo application as well. I'm confident in saying this PR is in good shape, but I won't know until it is in more hands.

Feel free to ask any specific questions. Thanks!