Closed epsi1on closed 4 years ago
Hello, @wo80 i think you already migrated CSParse to .net standard. Is it hard? can you please do a suggestion?
Thanks
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.
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.
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.
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
.
I also support migrating to .net standard. I can help out if required.
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
@epsi1on Please assign the issue, so we know who should be working on this.
Is it need all projects in solution be converted? or just few of them should be converted?
Thanks
I'd suggest to convert the following projects to net standard
and the test projects to net core (using NUnit for testing):
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.
Lets forget about BriefFiniteElement.Validation
in your list and convert others for now, so we'll
Convert these projects into .NET Standard
Convert these into .NET CORE (using NUnit for testing):
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
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?
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
0
I started working on this after your reply #69 (comment). Though you assigned @celeong, would a pull request be welcome?
Hi, Thanks, as you did it I've removed @celeong from assignee.
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?
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.
@epsi1on Do you have any idea why the appveyor ci isn't working?
@wo80 You are quick. I just got around to read the replies now.
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 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
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).
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 thenetstandard2.0
assembly).
OK, remove
i think it is done
Hi, Do you think it is necessary to migrate to .net standard or core or whatever dot-net version?
Thanks,