Migrate to .NET standard

[epsi1on]

Hi, Do you think it is necessary to migrate to .net standard or core or whatever dot-net version?

Thanks,

[epsi1on]

Hello, @wo80 i think you already migrated CSParse to .net standard. Is it hard? can you please do a suggestion?

Thanks

[wo80]

I think moving to .NET standard is a good idea. CSparse version 3.3.0 added .NET standard 2.0 support (and it was really easy to switch). If you want to support frameworks earlier than 4.6.1, you can add multiple target frameworks:

<TargetFrameworks>net40;net45;netstandard2.0</TargetFrameworks>

This would also be a good opportunity to remove some (or all) of the older solution/project files. Additionally, I think at some point there should be an up-to-date nuget package.

[wo80]

I think I will have some time to work on this at the weekend. I'll do a pull request then.

Two things: 1) I'd like to convert BriefFiniteElementNet.Common to a shared project. This would simplify the nuget package creation. 2) I'm not sure what the intent of the BriefFiniteElementNet.Solvers project is. Probably the same as I'm planning to do with CSparse.Extensions (anything related to solving linear systems), so the question is what project to keep? The BriefFiniteElementNet package would then (beside CSparse) also depend on that package. EDIT: actually this doesn't need to be a hard reference. Just a complementary package with additional solvers.

[rubsy92]

I also support the .net standard switch. It would be indeed handy and obsolete/old code could be tossed out while this change is happening. I'd be happy to help out where needed.

[epsi1on]

Thanks, I was planing to add new solvers like MKL etc without directly adding to main BriefFiniteElementNet projects. To do that, and to overcome circular project dependency, I made the BriefFiniteElement.Common and add ISolver to this project and BriefFiniteElementNet.Solvers to add any other solvers like MKL. Just wanted to keep BriefFiniteElement clean and without external dependency except CSparse.NET.

[celeong]

I also support migrating to .net standard. I can help out if required.

[epsi1on]

There are several projects in the solution, this is dependency graph of projects:

Detailed information:

https://github.com/BriefFiniteElementNet/BriefFiniteElement.Net/blob/master/SolutionProjects.md

[wo80]

@epsi1on Please assign the issue, so we know who should be working on this.

[epsi1on]

Is it need all projects in solution be converted? or just few of them should be converted?

Thanks

[wo80]

I'd suggest to convert the following projects to net standard

• BriefFiniteElement.Common
• BriefFiniteElement
• BriefFiniteElement.CustomElements
• BriefFiniteElement.Validation

and the test projects to net core (using NUnit for testing):

• BriefFiniteElement.Tests
• BriefFiniteElement.CustomElements.Test

BriefFiniteElement.Validation has a dependency on BriefFiniteElement.Controls, which should be removed (actually the whole GithubIssues subfolder should be removed or moved to another project, maybe BriefFiniteElementNet.TestConsole).

Again, I'd be glad to do this, I have some time this weekend.

[epsi1on]

Lets forget about BriefFiniteElement.Validation in your list and convert others for now, so we'll

Convert these projects into .NET Standard

• BriefFiniteElement.Common
• BriefFiniteElement
• BriefFiniteElement.CustomElements

Convert these into .NET CORE (using NUnit for testing):

• BriefFiniteElement.Tests
• BriefFiniteElement.CustomElements.Test

It would be great to also have some sort of automated nuget package build (for .net starting from 4.0, and .net core runtime) Thanks

[epsi1on]

I also support the .net standard switch. It would be indeed handy and obsolete/old code could be tossed out while this change is happening. I'd be happy to help out where needed.

What old code do you mean?

[wo80]

I started working on this after your reply https://github.com/BriefFiniteElementNet/BriefFiniteElement.Net/issues/69#issuecomment-670850591. Though you assigned @celeong, would a pull request be welcome?

See https://github.com/BriefFiniteElementNet/BriefFiniteElement.Net/compare/master...wo80:master

[epsi1on]

0

I started working on this after your reply #69 (comment). Though you assigned @celeong, would a pull request be welcome?

See master...wo80:master

Hi, Thanks, as you did it I've removed @celeong from assignee.

[epsi1on]

There are several sln files

as we migrated to .net standard, i think only VS2017 and newer versions can open the sdk-style projects, but not sure about it. maybe need to remove earlier sln versions?

[wo80]

i think only VS2017 and newer versions can open the sdk-style projects, but not sure about it. maybe need to remove earlier sln versions?

Yes, I'd suggest to just keep the 2019 solution file (and drop the VS2019 suffix) and also remove the corresponding BriefFiniteElementNet.DebuggerVisualizers project files.

[wo80]

@epsi1on Do you have any idea why the appveyor ci isn't working?

[celeong]

@wo80 You are quick. I just got around to read the replies now.

[celeong]

i think only VS2017 and newer versions can open the sdk-style projects, but not sure about it. maybe need to remove earlier sln versions?

Yes, I'd suggest to just keep the 2019 solution file (and drop the VS2019 suffix) and also remove the corresponding BriefFiniteElementNet.DebuggerVisualizers project files.

I can confirm only VS2017 and newer versions support the new SDK style projects. I agree we should keep only one solution file.

[epsi1on]

@epsi1on Do you have any idea why the appveyor ci isn't working?

Yes, i am fixing now edit: fixed, also old sln files are removed

[wo80]

The two *.CodeItRight.xml files can also be removed.

@epsi1on I saw you added netcoreapp2.0 as a target framework. I don't think this is necessary. If you look at the support table, you'll see that .NET Core 2.0 already implements .NET Standard 2.0 (both are equivalent, so a .NET core project would automatically choose the netstandard2.0 assembly).

[epsi1on]

The two *.CodeItRight.xml files can also be removed.

@epsi1on I saw you added netcoreapp2.0 as a target framework. I don't think this is necessary. If you look at the support table, you'll see that .NET Core 2.0 already implements .NET Standard 2.0 (both are equivalent, so a .NET core project would automatically choose the netstandard2.0 assembly).

OK, remove

[epsi1on]

i think it is done