Basic project integration stuck on adding property message

[supermartzin]

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:

Installed: False; 1.7.3+9a4bc51; invoked: 1.7.3
Project type: CsSdk
Storage: ProjectFiles
Compiler.Platform: Auto
Compiler.ordinalsBase: 1
Compiler.rSysObj: False
Compiler.ourILAsm: False
Compiler.customILAsm: 
Compiler.genExpLib: False
Compiler.peCheck: PeIl
Compiler.patches: None
PreProc.Type: None
PreProc.Cmd: 
PostProc.Type: None
PostProc.ProcEnv: $(SolutionPath);$(MSBuildThisFileFullPath)
PostProc.Cmd: 
SignAssembly: 
Identifier: F4EA5AE5-E3A3-4756-B804-ED16FBD8FC7B
Instance: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\amd64\MSBuild.exe
Project path: ~\Plugin\Plugin.csproj
Action: Configure
PlatformTarget: x86
TargetFramework: netstandard2.0
TargetFrameworks: 
TargetFrameworkVersion: 
RootNamespace: MTPro.Plugin
AssemblyName: 
MgrArgs: 
MetaLib: tools\raw\lib\net20\DllExport.dll
MetaCor: tools\raw\lib\netstd\DllExport.dll
Proxy: 
StoragePath: .net.dllexport.targets
ddNS: 
ddNS max buffer: 500
UseCecil: True
intermediateFiles: False
timeout: 30000
RootPath: ~
PkgPath: packages\\DllExport.1.7.3\
SlnFile: 
SlnDir: .\
DxpTarget: tools\net.r_eg.DllExport.targets
MsgGuiLevel: -1
LockIfError: 

Demo Project files / Samples / etc.:

Plugin.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <RootNamespace>MTPro.Plugin</RootNamespace>
    <Platforms>x86</Platforms>
    <PlatformTarget>x86</PlatformTarget>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="DllExport" Version="1.7.3" />
  </ItemGroup>
</Project>

. . .
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.

[hsaelens]

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.

[supermartzin]

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.

[supermartzin]

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.

[hsaelens]

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...

[supermartzin]

Interesting and how did you manage to add the RootPath? Have you modified the DllExportCfgTask class manually or changed it only via GUI?

Thanks!

[hsaelens]

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

[3F]

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"

DllExport/Wizard/net.r_eg.DllExport.Wizard.targets

Lines 42 to 48 in e9b20af

	<DllExportCfgTask
	RootPath="$(wRootPath)"
	SlnDir="$(wSlnDir)"
	SlnFile="$(wSlnFile)"
	PkgPath="$(wPkgPath)"
	MetaLib="$(wMetaLib)"
	MetaCor="$(wMetaCor)"

💊 Temp solution for DllExport 1.7+ including latest 1.7.3

Please use the following command, or like:

DllExport -packages="%cd%\packages" -sln-dir="%cd%"

Patch

@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.

[landrix]

the same thing happens to me too. and I thought I was too stupid. Thanks

[3F]

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

[3F]

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

[Chaoses-Ib]

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).

[3F]

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