Update .NET Framework to 4.8, migrate to sdk format #404
Conversation
SharpShell/Tools/ServerRegistrationManager/ServerRegistrationManager.csproj
Outdated
Show resolved
Hide resolved
|
Visual Studio 2017 is most likely too old. Should probably change appveyor.yml from |
• Make `Any CPU` the only build target, as `SharpShellNativeBridge` is no longer part of the main Solution
Repiteo
force-pushed
the
modernize-frameworks
branch
6 times, most recently
from
5382898 to
731bde6
Compare
|
I think you need to switch to use dotnet build instead of msbuild in build.ps1 (or maybe not required, but IIRC msbuild and sdk style csproj are not best friends and will fight from time to time) |
Repiteo
force-pushed
the
modernize-frameworks
branch
from
731bde6 to
0ae3a59
Compare
Repiteo
force-pushed
the
modernize-frameworks
branch
11 times, most recently
from
1851010 to
8abf591
Compare
Repiteo
force-pushed
the
modernize-frameworks
branch
2 times, most recently
from
46051a1 to
5c92782
Compare
• Remove all AssemblyInfo, migrate information to project when relevant • Remove legacy files that no longer link via new systems
Repiteo
force-pushed
the
modernize-frameworks
branch
from
5c92782 to
8c12288
Compare
Repiteo
force-pushed
the
modernize-frameworks
branch
7 times, most recently
from
120dd01 to
80c07b6
Compare
• Fix build warnings
Repiteo
force-pushed
the
modernize-frameworks
branch
from
80c07b6 to
cbbddd5
Compare
There was a problem hiding this comment.
Why is this file smaller? Or is it removed completely?
There was a problem hiding this comment.
Seems related to
https://github.com/dwmkerr/apex
https://www.nuget.org/packages/Apex
But file version is 1.6.0, so may be a private build that was never published to nuget, because last nuget is 1.5.0...
There was a problem hiding this comment.
But is it possible that Apex.WinForms.dll loads Apex.dll dynamically? Or is it truly unused?
There was a problem hiding this comment.
Everything certainly seems to function, but the file version is a good point. No clue why Apex.WinForms was never put on nuget
With .NET Core being in the air, this is something to bridge the gap in the meantime to allow modern Visual Studio instances to properly test and debug sharpshell as-is. Preliminary testing makes it seem like .NET Standard 2.0 could be another stopgap solution for the
SharpShelllogic specifically (the GUI stuff is another story), but that wouldn't be as smooth of a transition without first making sure everything functions as-is.