Build Issues - Notifications and Interaction with user

[eschatzy]

I was able to find a work around for these problems, but it is something that should probably be fixed.

I built my C# project with all the DllExport attributes over each method. There were no build errors or warnings. I tried to access the Dll from the calling project, but no functions were found. After a bit of digging, I found a post that suggested I set the build output to verbose/detailed. I was able to find two problems when building.

Problem 1:

• Cannot find lib.exe in 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE....\VC\bin'.
• There was no build warning or build error that this was an issue, without using verbose.

Solution 1:

• Figured out that I need to install the Common Tools for Visual C++ 20xx. (I'm a C# guy, not a C++ guy.)

Problem 2:

• Skipped method exports, because the platform target is neither x86 nor x64. Set the MsBuild property 'NoDllExportsForAnyCpu' to false if you want to create separate versions for x86 and x64. (e.g. you can do that in the package manager console: Set-NoDllExportsForAnyCpu -value $false)
• There was no build warning or build error that this was an issue, without using verbose.

Solution 2:

• Added an x86 solution platform using the Configuration Manager in Visual Studio.

It would be nice if there were some warning or error either during installation or at the time of building a project.

[3F]

For problem 1:

This is needed to create library.exp & library.lib - that is commonly used by LINK Output in C++ projects

and as you guessed, the DllExport also reproduces this steps for your new library via Microsoft Library Manager (LIB.exe)

i.e. the library that already has been modified by ILAsm + .export directive - look here or here details, how it works.

However, it's optional step. The final library.dll already should have your specified records in export table, and it also will work even via Conari engine.

btw, just noticed that's a good additional solution to solve problem with .net domains. I mean you should know about the "inconvenience" when you need destroy full domain to simply unload a single dll/.net assembly... need to think

But I also see that Robert also checks existence of this tool:

• https://github.com/3F/DllExport/blob/master/RGiesecke.DllExport/Parsing/ILAsm.cs#L165
• ValidateLibToolPath() (your message from here) for validation of existence via DevEnvDir or property DllExportLibToolPath from DllExport.targets.

so it already optional step...

What you need exactly for this ? :) the any message like for problem 0x80070005 that .exp & .lib cannot be created ?

[3F]

For problem 2:

I also think about some options to interact with user, for example, like I implemented with namespaces:

because even if you know about this restriction, you simply may forget about this and then to think... what's going on

[3F]

908a7c2 - I added GUI settings for problem 2:

you can check it from nightly builds before public release

• x86 + x64 - to get both versions at once

[3F]