Closed 3F closed 4 years ago
Latest hMSBuild changes includes -vsw-as
commands with the new default behavior.
3a02ed63847
Finally it helps to resolve "Sdk.WindowsDesktop" problem in actual 1.7-beta3 release (local report by Sg werweiss)
However, the fix depends on the published package and will not help until upgrading version at used channel.
The other temp command for old versions that can help before public release:
(set _x=DllExport -dxp-version 1.7.0-beta3 & call %_x% -action Default & for /F "tokens=*" %i in ('hMSBuild -only-path -vsw-priority Microsoft.NetCore.Component.SDK') do call %_x% -msb "%i")
+netstandard and netcoreapp project types.
Here's my explanation about today's solution:
Please comment and test while WIP.
Known problems
Other System.Object in modified assembly
Here details: https://github.com/3F/DllExport/issues/90#issuecomment-546637702
Some optional rebase is possible via my assembler feature 4.700.2+, see issue #125:
Possible incorrect Sdk-based project types
This is so because:
MvsSln project will resolve this problem through: https://github.com/3F/MvsSln/issues/23
But for our project today is also possible the way through https://github.com/3F/hMSBuild
I mean, works great:
~So I'm thinking about temporary integration hMSBuild into our DllExport.bat.~
~Or at least use from packages, eg. DllExport.1.6.5/hMSBuild.bat already provides this tool.~
MvsSln solution vs external hMSBuild
After testing the first beta releases, 1.7 most likely will contain the calling of external hMSBuild until MvsSln solution.
Closes #90, Closes #67 Cc: @NickAcPT, @PatVax, @longlostbro