Closed supermartzin closed 3 years ago
I have exactly the same behavior after upgrading VS to 16.8.1 two days ago. Using .Net 4.7.2.
This same project was building fine last week... I noticed the problem when all references to DllExport failed in the project. Running DllExport.bat again then gave the above errors. I tried removing all dllexport related PropertyGroups and Targets from the csproj-file first, but that did not make any difference.
I'm not sure if it is caused by the upgrade as I did it too because I have 2 other projects with DllExport library referenced (one with v1.6.2 on .NET Framework 4.7.1 and the other one is v1.7.0 on .NET 4.7) and they are still building fine with no problems.
But once I start a new project and try to add DllExport library there (either from NuGet or downloading it directly form GitHub releases) I always get stuck on the same message in the debug log.
Issue #170 seems very similar, I get similar behavior but there is a difference that I'm not using ILMerge preprocessing or any other customizations.
I think I found the problem in my case. Somehow the RootPath is not added in front of the PkgPath internally. Once I force the code in DllExportCfgTask.cs to add it, everything works fine again.
Another thing that was not working in my case was the Build Info tab. It showed "Detailed information about build was not found :(". because C:\mySolution\packages\DllExport.1.7.3\tools\packages\DllExport.1.7.3\build_info.txt could not be found. After my change, it correctly showed the content of the file at C:\mySolution\packages\DllExport.1.7.3\build_info.txt.
I have no idea why this worked before and now stopped working...
Interesting and how did you manage to add the RootPath
? Have you modified the DllExportCfgTask
class manually or changed it only via GUI?
Thanks!
See the patch in attachment. My guess is that the PkgPath is being set before the RootPath. There may very well be a better way to fix this, I just started using dllExport a few weeks ago and know almost nothing about how it does its magic... 0001-Quick-fix-for-issue-175.patch.txt
Thanks for the report!
Seems like it was some changes in modern MSBuild instances for ITask processing (distributed together with VS 16.8+ and Build Tools). Because I remember an oriented vector at init properties before 16.8
DllExport -msb "...old-instance...MSBuild.exe"
Please use the following command, or like:
DllExport -packages="%cd%\packages" -sln-dir="%cd%"
@hsaelens almost correctly noticed the place of the problem!
Since it might be some multithreading optimization in modern instances (not sure, need to check src), now it would be a good thing to separate the initialization logic.
RootPath="$(wRootPath)"
must be first in any use of associated DirectoryPathFormat() / FilePathFormat() extensions etc.
I can review PR later. Thanks.
the same thing happens to me too. and I thought I was too stupid. Thanks
Guys! Please note the actual evaluation of the %cd%
in my temp solution above. That's why you need temporarily apply this also for restoring remote package (if so).
The case if you're working with different paths (team, CI, any distribution of src without our package inside). Before VS/build:
DllExport -action Restore -packages="%cd%\packages" -sln-dir="%cd%"
Sorry for the inconvenience https://twitter.com/GitHub3F/status/1320425255291265026
Please test the fix before merge using command:
DllExport -force -pkg-link https://ci.appveyor.com/api/buildjobs/flylkoo0c9ggab9g/artifacts/bin/Release/DllExport.1.7.3.nupkg
Please test the fix before merge using command:
DllExport -force -pkg-link https://ci.appveyor.com/api/buildjobs/flylkoo0c9ggab9g/artifacts/bin/Release/DllExport.1.7.3.nupkg
It works in VS 16.8.3 (both .NET Fx 4.8 and .NET Standard 2.0).
It works in VS 16.8.3 (both .NET Fx 4.8 and .NET Standard 2.0).
Good! I'll quickly review other important bugs in 1.7.4. The release will be soon as possible for me.
Here's with the new more loyal logic when no keys for some reason:
DllExport -force -pkg-link https://ci.appveyor.com/api/buildjobs/aed8cgsk67jpsuno/artifacts/bin/Release/DllExport.1.7.3.nupkg
Steps to reproduce:
create simple Class library project for .NET Standard 2.0
install DllExport via NuGet
in GUI, select project, tick x86 and press Apply, the log keeps hanging on
[Debug] 'Plugin\Plugin.csproj' Schedule an adding property: 'DllExportIdent':'0FAA5C33-ECB9-49BF-AB5B-F3DC54C76B08
. . .DllExport version:
v1.7.3.58831+9a4bc51
Used Visual Studio 2019 16.8 and also tested on Visual Studio Build Tools 2019
Information from
Data
tab or log data:Demo Project files / Samples / etc.:
Plugin.csproj:
. . . I'm not sure why but it keeps hanging on that Schedule and adding property message even with the simplest example code. Tried on different frameworks (.NET Core 3.1, .NET Standard 2.0, .NET Framework 4.7.1) also on a different machine, the result is the same.