I wanna stop a memory leak, no ideia to do this without a event while end the process.

So, it would allow to export methods at desired ordinal.

Tried to install in Visual Studio 2013 and got Import-Module error.

I am exporting some functions using DLLExport which is working great.
But I also need to export a Variable (Pointer to a FunctionPointer-Structure), which will be set from the native application loading my assembly and I then want to call a function in that struct from within my managed code.

So what i want to do basically (simpilfied):

[DLLExport]
FuncPtrStruct EXPORTVAR;

public double GetExternalValue(Int32 index)
{
if (EXPORTVAR == null)
return -1;
return EXPORTVAR->get_nativedata(index);
}

where get_indexdata would be defined as
"double (__stdcall *get_indexdata) (int index)" in the struct

So what else apart from DLLExport will I need, or would it maybe easier to write a native dll that provides the exported variable, handles the calls to it and loads my managed assembly, communicating with it through exported functions?

Hints welcome.

I just spent HOURS debugging the following problem.

My DLL stopped working after some code changes. There was this one function call that would always cause an unhandled exception regardless of my error handling.

Do you see the error?

[DllExport("DoStuff", CallingConvention = CallingConvention.StdCall)]
[return: MarshalAs(UnmanagedType.LPWStr)]
public static bool DoStuff([MarshalAs(UnmanagedType.LPWStr)] string inp1, [MarshalAs(UnmanagedType.LPWStr)] string inp2, double inp3, double inp4)
{
    try
    {
        return ResultOfDoingStuff(inp1, inp2, inp3, inp4);
    }
    catch
    {
        return false;
    }
}

Note that as the entire function body is enclosed in a try block, and as the corresponding catch is nigh on empty, there doesn't seem to be any code that could cause an exception.

Any ideas?

No? Then compare lines 2 and 3. According to line 2 the output is marshalled as a string pointer, but according to line 3 the output is a bool. It compiles beautifully, no mess, no fuss, and then it crashes horribly for a nigh on undetectable reason.

I have no idea how DLLExport works, so I don't know if a warning or error would be easy to implement. In any case let this be a warning to future passers by: "Marshall only when necessary."

I am sorry about all the questions. I do not know well if you search on Google, so please let me know.
Can I pass an array from JNA to .net using UnmanagedExports?

Here is my code

//java
int arr = new int[2];
arr[0] = 1;
arr[1] = 2;
test(arr);

//JNA
public interface VbWrapper extends Library {
public int test(int[] intArr);
}

//.net
<DllExport("test", CallingConvention.StdCall)>
Function test(ByVal arr() As Integer) As Integer
MsgBox(arr.length) ' printed 1
MsgBox(arr(1)) ' invalid memory access 

Am I making a mistake?

I want to call vb.net ByRef and String function from java.
vb.net dll is maked by UnmanagedExports.

//java
String[] str = {"testJavaWrited"};
String[] str2 = {"testJavaWrited2"};
final VbWrapper wr = (VbWrapper)Native.loadLibrary("vbtestlib", VbWrapper.class);
wr.test(str,str2);
System.out.println(str); // not printed
System.out.println(str2); // not printed

// jna mapping
public interface VbWrapper extends Library {
public int test(String[] str,String[] str2);
}

//vb.net
<DllExport("test", CallingConvention.StdCall)>
Function test(ByRef str As String, ByRef str2 As String) As Integer
MsgBox("test Called") ' printed
MsgBox(str) ' printed
str = "testStringWrited"
str2 = "testStringWrited2"
Return 0
End Function ' heap error

I need your help everybody.

http://stackoverflow.com/questions/41830352/how-to-call-jna-to-vb-net-byref-string-function

I seem to be unable to load debug information for projects where I use DLLExport v1.5.1.
I have seen the issue in both Visual Studio 2013 and 2015.

I can load .pdb-files when using DLLExport 1.4.0, without problem.
I have also uploaded a simple sample project, which reproduce the issue.

DLLExportPdbTest.zip

For example:
Say, assembly is marked: [assembly: DllExportInclude("exportme_*")]
It would export all static methods from assembly whose name matches the specified pattern (in this case exportme_*).

It would also be nice to have DllExportExclude attribute which could be applied to assembly, types, methods (etc.), but that would work exactly the opposite of DllExportInclude.

Edit:
Here are some notes:

• Inner-most member should have the highest priority, e.g:

[assembly: DllExportExclude("exportme_*")]
// ...
[DllExport]
public static void exportme_Method()
// ...

In such case, since exportme_Method method is explicitly marked to be exported, but assembly is marked the opposite of it, exportme_Method should still be exported.

Since we have a lot of problems/inconvenience with new nuget features like a global caching, new PackageReference format, removed install/uninstall ps-scripts, and the overall focus on libraries only, I'll consider new destribution via our compact GetNuTool client (or something else, not important). That is, this package still will be placed via any nuget server, but without any guarantee for support of any standard client.

Because I'm tired from nuget project -_- in recent years it's very inconvenient for any tools, because of main focus to libraries (that's soundly not for all cases).

GetNuTool (batch file about 10kb) has been created primarily to provide tools and service of user projects, libraries, the build processes, etc.
It especially used by vsSolutionBuildEvent projects (CIM library for support CI features) because of removed solution-level in 2015

Thus, probably we need to reconsider new way for distribution our tool for best support.

Related issue: #36 (comment)

How it can be (draft)

gnt.core can be wrapped to 1 batch file (text-based file, who don't know) that will:

• Receive our tool, then interact (if new installation) with user for complete installation for selected project (as for today).

Requirements: no any, GetNuTool works via msbuild like your common build. And logic will be placed in 1 batch file, that you can store with your code as simple build-script.

Problems

But GetNuTool is oriented for solution-level only, therefore we need also provide support to add our settings & required targets for user project-files.

For this I can encapsulate logic of this inside our package from vsSolutionBuildEvent project (I think part of this I can open by new MIT license), and main scheme should be like:

batch -> package -> {installation} -> {logic from vsSolutionBuildEvent} -> {imported targets and configuration} -> done

so I think it should be fine.

Pros / cons

+

• Best support of our package as we need in any time.
• 1 batch files that may aggregate any configuration and easily stored with other your source code, or directly in any other scripts and so on...
• Probably it takes as much work for implementation as for all support of all this zoo. So it's not important (for me at least) this or full review of current obsolete variants. Well I think <_<

-

• Misunderstanding for new users via current NuGet server - why install command not works properly. (partially resolved)
• ... please comment about possible problems for you.

So what anyone think about this ? Your suggestions ?

private static void Main(string[] args)
{
    Print(__arglist("Hello", ' ', "with arglist."));
    Print("Hello", ' ', "with params.");
    Pause();
}

[DllExport]
public static void Pause()
{
    try
    {
        Console.ReadKey(true);
    }
    catch (InvalidOperationException)
    {
        Console.Read();
    }
}

[DllExport(nameof(Print) + "_arglist")]
public static void Print(__arglist) // Export as "Print_arglist"
{
    ArgIterator argIterator = new ArgIterator(__arglist);
    while (argIterator.GetRemainingCount() > 0)
    {
        TypedReference typedReference = argIterator.GetNextArg();
        object obj = TypedReference.ToObject(typedReference);
        Console.WriteLine(obj);
    }
}

[DllExport(nameof(Print) + "_params")]
public static void Print(params object[] args) // Export as "Print_params"
{
    foreach (object obj in args)
    {
        Console.WriteLine(obj);
    }
}

If you try to compile the program from above (note: C# 6), it is going to fail with the following error message:

DllExport.1.3.0\tools\net.r_eg.DllExport.targets(59,5): error : An item with the same key has already been added.

Also, it is the same thing as with UnmanagedExports:

UnmanagedExports.1.2.7\tools\RGiesecke.DllExport.targets(58,3): error : An item with the same key has already been added.

Failed when is used signed assembly by .snk or .pfx key

DllExport.targets(58,5): error : Assembling 'C:\Users\reg\AppData\Local\Temp\tmp88A8\Gateway.il'  to DLL --> 'D:\prg\qsin\bin\Debug\Gateway.dll'
DllExport.targets(58,5): error : Source file is UNICODE
DllExport.targets(58,5): error : 
DllExport.targets(58,5): error : Assembled method Gateway.Connector::entrypoint
DllExport.targets(58,5): error : Assembled method Gateway.Connector::onProc
DllExport.targets(58,5): error : Assembled method Gateway.Lua::.ctor
DllExport.targets(58,5): error : Creating PE file
DllExport.targets(58,5): error : Could not create output file, error code=0x80070005
DllExport.targets(58,5): error : 
DllExport.targets(58,5): error : ***** FAILURE ***** 

Same for original tool (v1.2.7)... hmm

When can we expect to see a NuGet update get published? Issue #37, to which I anxiously await a fix, appears to have been resolved and checked in some time ago. However, a NuGet to support it has not been published. In our production application, I would much prefer a NuGet to building the project myself.

Having said that, there seems to be some discrepancy about whether or not issue #37 is actually fixed, but that's a different topic. :-)

Thanks!
Brad.

Projects in VS 2017 no longer use ps1 scripts for install/uninstall. They are not called.

Instead, a package can provide a \build\<tfm>\packagename.targets file that will automatically get imported. In this case, it'd be \build\net20\DllExport.targets.

Noticed earlier: #38 (comment)

<PropertyGroup Condition=" '$(DllExportIdent)' == '6C994FF1-7B8B-4B8F-B1EB-FC8B66EDF8B3' ">
  <DllExportNamespace>System.Runtime.InteropServices</DllExportNamespace>
  ...
</PropertyGroup>
<PropertyGroup Condition=" '$(DllExportIdent)' == '0415A0AA-76E4-43A4-BDC3-D115A6781C7D' ">
  <DllExportNamespace>net.r_eg.DllExport</DllExportNamespace>
  ...
</PropertyGroup>
<ItemGroup>
  <Reference Include="DllExport, Version=1.6.0.40687, Culture=neutral, PublicKeyToken=8337224c9ad9e356">
    <HintPath>..\packages\DllExport.1.6.0-beta2\gcache\metalib\DllExportClassLibrary1\DllExport.dll</HintPath>
    <Private>False</Private>
  </Reference>
</ItemGroup>
....

It helps to avoid reloading environment outside EnvDTE logic, and actually looks more flexible.

That is, user should to see finally .net.dllexport inside $(SolutionDir) and manage this via our manager or directly.

Hi!
I'm attempting to use this package in some projects and I was getting some script errors on install. I have created a minimum project for testing this and it's continued to occur. I suspect this is a user error on my part rather than anything, but I thought I'd post here to ask one way or another.
After running Install-Package DllExport, I get a dialogbox asking for a namespace (not clear what this is supposed to be?). After entering something (I've tried unique namespaces as well as the namespace of the classes containing things I would like to export), I get the following errors:

Executing script file 'c:\Users\alex\documents\visual studio 2015\Projects\dllTest\packages\DllExport.1.3.0\tools\install.ps1'
The term 'nsbin.ps1' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At C:\Users\alex\documents\visual studio 2015\Projects\dllTest\packages\DllExport.1.3.0\tools\install.ps1:77 char:2
+ . <<<<  "nsbin.ps1"
    + CategoryInfo          : ObjectNotFound: (nsbin.ps1:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

The term 'defNS' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At C:\Users\alex\documents\visual studio 2015\Projects\dllTest\packages\DllExport.1.3.0\tools\install.ps1:78 char:6
+ defNS <<<<  $([System.IO.Path]::Combine($installPath, 'lib\net20', $assemblyFName + '.dll'))  $vNamespace
    + CategoryInfo          : ObjectNotFound: (defNS:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Attempting to build after this occurs results in the build running forever (or at least a few hours) without finishing/failing.

Thanks for your help!

Hello, anyone has ever tried to use ILmerge to combine a lot of resulting assemblies into a compact assembly and transform it to dll library?

Also, any assembly manipulation like code obfuscators fails always.

Its possible to process normally the assemblies then make the build task?

Regards

Hi,

I'm using DllExport Nuget package within Visual Studio and it works just great.

However, I was wondering how (if possible) to get the same result using only command line compiler such as csc.exe. Of course, I can add the /reference:path_to_dll_export.dll and the cs files will compile just fine, but the resulting DLL doesn't actually export any function. I guess that's because the DllExport magic happens after compilation by modifying the export section of the IL... (I barely understand this part).

So, does it sound feasible ?

Thanks,
Arno

just a note:

Now I added support of unmanaged-export for Executable Modules (.exe)

Before this, you could see something like:

Unable to start program '<Your_Application>.exe'.
... is not a valid Win32 application.

Now should work as and for library modules.
But important note: to debug of this modified .exe inside Visual Studio you should disable Debug - Enable the Visual Studio hosting process

Hello,

trying to extend a project for unmanaged exports, but when I build the project I get the error:

"Provided key file 'C:\Users\user\documents\visual studio 2017\Projects\ClassLibrary1\ManagedDLL_test\Mono.Cecil.CustomAttributeArgument' cannot be found."

It cannot find the existing snk file or anything else?
Thanks!

Hi

I have installed the NuGet package (v1.5.2) to an .NET 4.6.1 library Project. There are two issues:

1. The DllExportAttribute resides in a very strange Namespace: "D3F00FF1770DED978EC774BA389F2DC901F4.B00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.C00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.D00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.E00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.F00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"

2. When I build the Project (x64) no *.lib is generated which can be linked by my C++ lib

PowerShell path: "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe" 
1>  Import-Module : Could not load file or assembly 'file:///C:\Users\Administrator
1>  \Documents\Visual Studio 2017\Projects\Project1\packages\DllExport.1.
1>  5.2\tools\NSBin.dll' or one of its dependencies. This assembly is built by a ru
1>  ntime newer than the currently loaded runtime and cannot be loaded.
1>  At line:1 char:2
1>  + & <<<<  Import-Module "C:\Users\Administrator\Documents\Visual Studio 2017\Pr
1>  ojects\Project1\packages\DllExport.1.5.2\tools\/NSBin.dll"; Set-DDNS 
1>  -Dll "C:\Users\Administrator\Documents\Visual Studio 2017\Projects\Project1
1>  \packages\DllExport.1.5.2\tools\..\lib\net20\DllExport.dll" -Namespace "S
1>  ystem.Runtime.InteropServices" -UseCecil $true 
1>      + CategoryInfo          : NotSpecified: (:) [Import-Module], BadImageForma 
1>     tException
1>      + FullyQualifiedErrorId : System.BadImageFormatException,Microsoft.PowerSh 
1>     ell.Commands.ImportModuleCommand
1>   
1>  The term 'Set-DDNS' is not recognized as the name of a cmdlet, function, script
1>   file, or operable program. Check the spelling of the name, or if a path was in
1>  cluded, verify that the path is correct and try again.
1>  At line:1 char:150
1>  + & Import-Module "C:\Users\Administrator\Documents\Visual Studio 2017\Projects
1>  \Project1\packages\DllExport.1.5.2\tools\/NSBin.dll"; Set-DDNS <<<<  
1>  -Dll "C:\Users\Administrator\Documents\Visual Studio 2017\Projects\Project1
1>  \packages\DllExport.1.5.2\tools\..\lib\net20\DllExport.dll" -Namespace "S
1>  ystem.Runtime.InteropServices" -UseCecil $true 
1>      + CategoryInfo          : ObjectNotFound: (Set-DDNS:String) [], CommandNot 
1>     FoundException
1>      + FullyQualifiedErrorId : CommandNotFoundException
1>   
1>C:\Users\Administrator\Documents\Visual Studio 2017\Projects\Project1\packages\DllExport.1.5.2\tools\net.r_eg.DllExport.targets(70,7): error MSB3073: The command "NSBin.bat "C:\Users\Administrator\Documents\Visual Studio 2017\Projects\Project1\packages\DllExport.1.5.2\tools\..\lib\net20\DllExport.dll" "System.Runtime.InteropServices" "true"" exited with code 1.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

The problem subsists with .NET 4.7

That would be funny if it could be possible.

reported by @ArgusMagnus here #33 (comment)

temp solution #33 (comment)

<installationPath>\<Version>\<Edition>\VC\Tools\MSVC\<Version>\bin\<HostTarget>\<Arch>

<DllExportLibToolPath>$(DevEnvDir)\..\..\VC\bin;$(DevEnvDir)..\..\VC\Tools\MSVC\14.11.25301\bin\HostX86\x86</DllExportLibToolPath>

Good news !

yesterday, Robert contacted with me and sent an invite to bitbucket repo:

• https://bitbucket.org/RobertGiesecke/unmanaged-exports (currently, private access only)

He also plans to open it for all on GitHub ! So it will be soon :)

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.

Hello,

I'd like to clarify a couple of things for myself regarding DllExport that are still obscure to me.

• Is there any support for platforms other than Windows? I.e., is it possible to export C# library into an .so library for Linux?
• What exactly happens when we export using DllExport? Does it AOT-compile everything to native code and statically link it together in the DLL or it would require .NET Framework installed on the end-user machine anyway?

Edit: Never mind.... I found it. Now to see if I can get FORTRAN to talk to to.

Trying to get a C# project set up so I can call it from a FORTRAN program. Really!

Tried about everything I could here including installing the 8f75a86 build. Still no .lib file.
New to VS2017 so it takes a bit to figure out where things are. And last did any thing if VS years ago.

Microsoft Visual Studio Professional 2017
Version 15.2 (26430.16) Release
VisualStudio.15.Release/15.2.0+26430.16
Microsoft .NET Framework
Version 4.7.02046
Installed Version: Professional
Visual Basic 2017 00369-60000-00001-AA283
Microsoft Visual Basic 2017
Visual C# 2017 00369-60000-00001-AA283
Microsoft Visual C# 2017
Visual C++ 2017 00369-60000-00001-AA283
Microsoft Visual C++ 2017

whoops... current default values are not correct for DllExportAttribute, because today this used only with CustomAttribute -> ConstructorArguments

just noticed -_-

i.e. all below will not work (usage to initialize):

public DllExportAttribute(string function)
    : this(function, CallingConvention.Cdecl)
{
    ...
}

...

public CallingConvention CallingConvention
{
    get;
    set;
} = CallingConvention.Cdecl;

....

public DllExportAttribute()
{
    CallingConvention = CallingConvention.Cdecl;
}

etc.

ok, I'll fix it coming soon

Hi,

in the source code:
The file Configurator/ConfVersion.cs is missing and was probably not checked in..
For the moment the master does not compile.

MFG

the request about official support of this feature, here:

• c# adding [DllExport] feature #1013

and:

If you prepare a pull request, please call it to my attention and I will shepherd it.

so, TODO

Reference to DllExport is always removed, which may be unwanted in some situations.

What I would suggest to do is:
Search compilation symbols for DLLEXPORT_PRESERVE, and if it is present, do not remove reference to DllExport, otherwise keep current behavior.

-_- need to improve this moment because can be misunderstanding for simply removing then installing operations etc.

Currently it was implemented via temp. assemblies to avoid locks after loading into domain.
But no... no, no ! We have more problems than good.

Later, I will try my old variant from Actions/ActionCSharp that allows generating of the same file as .net library from different C# code at runtime

There it works perfectly* without additional domains, proxy-objects, temp files, etc. Or something else. just TODO
*well, with important note :) but I think it also good way for this case

After adding DllExport from nuget I get this error.

Severity	Code	Description	Project	File	Line	Suppression State
Error		The command "NSBin.bat "C:\Users\Cloud\Documents\Visual Studio 2017\Projects\DllExportTest\packages\DllExport.1.5.2\tools\..\lib\net20\DllExport.dll" "System.Runtime.InteropServices" "true"" exited with code 1.	DllExportTest

Also my other question is why is the namespace so long or have i done something incorrectly? https://gyazo.com/a1650335764e5e4b3f0b447c0bdd2b57

Next, are there any example projects of using DllExport? I attempted to bypass the NSBIN.bat by simply clearing the code in the batch file out. However once compiled i used IDA and DependencyWalker to see if the export was actually exported and did not see anything.

And lastly, i see in some of your screenshots there is a configurator. I, however, do not see this in VS2017 so is there a fix for that?

The following keep poping up across screen (also notice "Cannot resolve symbol"):

Though I do like idea of "dynamic definition of namespace", it is very annoying and clearly was not made to support Re#, apparently it was introduced in #2. Which is not the case with (original) UnmanagedExports NuGet package (where namespace is static).

Can't build the program any more, it fails because of this error:

...\packages\DllExport.1.5.0\tools\net.r_eg.DllExport.targets(42,5): error : error : Failed to define security permission set for 0x20000001

I'm running VS2015 with administrator privileges, and I've just upgraded DllExport to v1.5.

I have discovered this bug a while ago and I am surprised to see that it is still not fixed.
Note: This bug is specific to DllExport code/package (any version)! Such bug does not exist in UnmanagedExports code/package (v1.2.7).

For example:

1. Create a new C# class library project.
2. Download/Install DllExport into project via NuGet (Install-Package DllExport, pick any version, the newest release v1.5.2 is still affected by this bug).
3. Use whatever DllExport configuration options you want, it doesn't matter at all.
4. Go to Project -> Properties -> Build Events page.
5. Enter (or copy/paste) the following into post-build command line:
   COPY /Y "$(TargetPath)" "$(SolutionDir)$(TargetFileName)"

You should have something like this:

Next, build the project and wait for it to complete.
The above simple post-build event should copy the compiled DLL with exports into another directory (overwriting the existing file if it exists).
However, it seems that it instead copies compiled DLL without any exports into another directory.

And like I already said, this is not the case with UnmanagedExports package; post-build event works fine with UnmanagedExports package, apparently this bug has been introduced in DllExport code/package!

To speed things up, you can download my example (DllExport) VS2017 solution from here:
DllExport-PostBuild-issue.zip

And here you can also download another example VS2017 solution which uses UnmanagedExports package instead (to see that post-build works correctly with it):
UnmanagedExports-PostBuild.zip

Please fix DllExport :)

I have discovered a bug in DllExport (v1.5.2), it breaks the compilation with the following error:

The "DllExportAppDomainIsolatedTask" task failed unexpectedly.
System.ArgumentException: Unknown cpu platform 'MyCustomPlatform'.
Parameter name: platformTarget

Server stack trace: 
   at RGiesecke.DllExport.Utilities.ToCpuPlatform(String platformTarget) in D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport\Utilities.cs:line 76
   at RGiesecke.DllExport.MSBuild.ExportTaskImplementation`1.Execute() in D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport.MSBuild\RGiesecke.DllExport.MSBuild\ExportTaskImplementation.cs:line 414
   at RGiesecke.DllExport.MSBuild.DllExportAppDomainIsolatedTask.Execute() in D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport.MSBuild\RGiesecke.DllExport.MSBuild\DllExportAppDomainIsolatedTask.cs:line 397
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Microsoft.Build.Framework.ITask.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()	DllExport			

For easier reproducing of this issue, you can download VS2017 solution from here, and then try to build it:
DllExport-Platform-issue.zip

Please examine C# project file in the file attached above. You will see that PlatformTarget is set to x86, but $(Platform) is set to MyCustomPlatform.
The bug is that DllExport uses the incorrect value for detecting "target platform" value. As you can see, it obviously uses $(Platform) (MyCustomPlatform) instead of PlatformTarget (x86).
And here is the picture of that:

Please fix it :)

 Error : Invalid Option: /CVRES=C:\Windows\Microsoft.NET\Framework\v4.0.30319/

When DllExportOurILAsm as false:

<DllExportOurILAsm>false</DllExportOurILAsm>

My typo, I will fix it later. Temporarily, please use true

Building on my computer works fine, but i'm having a hard time building on my build server (TFS 2010).
Using msbuild tools 14.0, targetting .net 4.0.
I get this error :
Sorry for the french-ish stacktrace

D:\Builds\35\MyProject\Sources\packages\DllExport.1.5.0\tools\net.r_eg.DllExport.targets(42,5): error :  [D:\Builds\35\MyProject\Sources\Client\Client.csproj]
     à RGiesecke.DllExport.Parsing.IlParser.RunIlTool(String installPath, String toolFileName, String requiredPaths, String workingDirectory, String settingsName, String arguments, String toolLoggingCode, String verboseLoggingCode, IDllExportNotifier notifier, Int32 timeout, Func`2 suppressErrorOutputLine) dans D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport\Parsing\IlParser.cs:ligne 378
     à RGiesecke.DllExport.Parsing.IlDasm.Run() dans D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport\Parsing\ILDasm.cs:ligne 22
     à RGiesecke.DllExport.DllExportWeaver.RunIlDasm(String tempDirectory) dans D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport\DllExportWeaver.cs:ligne 188
     à RGiesecke.DllExport.DllExportWeaver.Run() dans D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport\DllExportWeaver.cs:ligne 51
     à RGiesecke.DllExport.MSBuild.ExportTaskImplementation`1.Execute() dans D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport.MSBuild\RGiesecke.DllExport.MSBuild\ExportTaskImplementation.cs:ligne 437

Any idea ?

I think the title says it all.
Ordinal is not as index, thus it should start counting from 1 rather than 0.
Open any native Windows DLL with dumpbin /EXPORTS (or use PE explorer program), and you will notice that ordinal always starts from 1.

Read this comment.

Depends on:

• 3F/coreclr#4 - Improve ILAsm grammar for export variables into Export Directory (IMAGE_OPTIONAL_HEADER - NT PE32/PE32+)

If I add DllExport to a project, then close the project and then open it again, then none of the references in my project can be found, including basic .NET namespaces.

If I close the project, then remove the following line from my .csproj, then reopen it, the references magically come back. But then, of course, the DllExport stuff no longer works.

  <Import Project="../packages/DllExport.1.5.2/tools/net.r_eg.DllExport.targets" Condition="Exists('../packages/DllExport.1.5.2/tools/net.r_eg.DllExport.targets')" />

Any ideas?

I want to call the dll output by unmanagedexportts from JNA.
However, all dlls that are dependent on dll must be placed in the same folder as JRE.
I think it would be nice if there was a way to go to load dll in the same folder as dll in a folder different from JRE. I would like you to tell me if there is something else in a different way.

java-native-access/jna#590

[AttributeUsage(AttributeTargets.Method/*, AllowMultiple = false*/, Inherited = false)]
public sealed class DllExportAttribute : Attribute

For more information, see this page.

If I have some sort of package hierarchy, it is unreasonable to expect that packages/applications down the chain should use my namespace. If it is undesirable to ship a DLL with this Nuget package that contains this attribute, it should be possible to inject the DllExport attribute into the global namespace if so desired.

Currently

1. The dialog does not accept an empty string as a namespace
2. When given the string "global", it create a literal namespace called "global" (@global) instead of using the global namespace.

Currently the ugly hack I'm having to use is to include a namespace that descendants should not have to know about or care at all. Could this be fixed by simply allowing empty string to represent the global namespace?

pythonnet/pythonnet#220

the issue is:

syntax error at token '.field' in: .field static assembly initonly int64

and the manual solution is:

yajiedesign commented 3 days ago
ok,I found and fixed the problem.
RGiesecke.DllExport does not support non English ILdasm generated IL file.
you can pathed RGiesecke.DllExport with ilspy fixed it
find and change "// Code" to you system language.
it in RGiesecke.DllExport.Parsing.Actions.DeleteExportAttributeParserAction.Execute

Updated

via Cecil or direct modification:

I implemented byte-structure for v1.2+

// byte-seq via chars: 
// + Identifier        = [32]bytes
// + size of buffer    = [ 4]bytes (range: 0000 - FFF9; reserved: FFFA - FFFF)
// + buffer of n size
D3F00FF1770DED978EC774BA389F2DC901F4 // 01F4 - allocated buffer size
.B00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 // 100
.C00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
.D00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
.E00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
.F00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
//= 536

... and you can use what you want, for example System.Runtime.InteropServices or namespace of your project net.r_eg.Conari etc.

+the illustration via Object Browser of VS2015:

click on image to maximize or here

v1.4+ new configurator:

for old v1.1:

System.Runtime.InteropServices;

The DllExport have a special case for naming i.e. in any case cannot be 2 or more different projects for work with similar features DllExport - because it's ambiguity of logic at all, because it's a tool and not a library. So, even if this feature will appear from official MS, it not problem at all, because the any custom DllExport will be obsolete and removed from project at all.

You cannot make those kinds of assumptions.

yes, of course, but 'as is' - the System.Runtime.InteropServices exists for specific purposes only.
anyone else :) do not should use something (inc. "another library that helps e.g. with marshaling") inside this namespace because it may intersect with something else in future. And it problem should known for developers that distributed their other features.

It means for DllExport & InteropServices it more likely a theoretical-potential problems, but yes, conflicts are possible.

Therefore, to avoid any the theoretical-potential problems of this case, the easy way to provide auto-variants of this assembly, this is common way for any cases.
With vssbe scripts or something else, I will just add later 2 auto-build of nupkg or something else. So candy for all tastes ...

When using C# 4.6 +

Severity Code Description Project File Line Suppression State
Error The "DllExportAppDomainIsolatedTask" task failed unexpectedly.
System.ArgumentException: Requested value 'Version46' was not found.

Server stack trace:
at System.Enum.EnumResult.SetFailure(ParseFailureKind failure, String failureMessageID, Object failureMessageFormatArgument)
at System.Enum.TryParseEnum(Type enumType, String value, Boolean ignoreCase, EnumResult& parseResult)
at System.Enum.Parse(Type enumType, String value, Boolean ignoreCase)
at RGiesecke.DllExport.MSBuild.ExportTaskImplementation1.<>c__DisplayClass126_0.<GetGetToolPathInternal>b__1(Version version, String toolName) in D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport.MSBuild\RGiesecke.DllExport.MSBuild\ExportTaskImplementation.cs:line 608 at RGiesecke.DllExport.MSBuild.ExportTaskImplementation1.TryToGetToolDirForFxVersion(String toolFileName, Func3 getToolPath, String& toolDirectory) in D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport.MSBuild\RGiesecke.DllExport.MSBuild\ExportTaskImplementation.cs:line 775 at RGiesecke.DllExport.MSBuild.ExportTaskImplementation1.ValidateToolPath(String toolFileName, String currentValue, Func3 getToolPath, String& foundPath) in D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport.MSBuild\RGiesecke.DllExport.MSBuild\ExportTaskImplementation.cs:line 756 at RGiesecke.DllExport.MSBuild.ExportTaskImplementation1.ValidateFrameworkPath() in D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport.MSBuild\RGiesecke.DllExport.MSBuild\ExportTaskImplementation.cs:line 722
at RGiesecke.DllExport.MSBuild.ExportTaskImplementation1.ValidateInputValues() in D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport.MSBuild\RGiesecke.DllExport.MSBuild\ExportTaskImplementation.cs:line 507 at RGiesecke.DllExport.MSBuild.ExportTaskImplementation1.Execute() in D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport.MSBuild\RGiesecke.DllExport.MSBuild\ExportTaskImplementation.cs:line 410
at RGiesecke.DllExport.MSBuild.DllExportAppDomainIsolatedTask.Execute() in D:\prg\projects\DllExport\DllExport\RGiesecke.DllExport.MSBuild\RGiesecke.DllExport.MSBuild\DllExportAppDomainIsolatedTask.cs:line 397
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.Build.Framework.ITask.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext() TestDll

I recently upgraded from Visual Studio 2013 to 2015 and my projects where I used both DLL Export and Fody (More specifically ModuleInit.Fody) stopped working.

I have tried the same project on different computers with different versions of Visual Studio 2015. Same issue on all computers.

It seem as i can't use DLL Export together with Fody (e.g. ModuleInit). Both tools works great separately, but when both is included in a project the build fails.

The build error I get:

Severity    Code    Description Project File    Line    Suppression State
Error       C:\Users\[...]\AppData\Local\Temp\tmp4CC9\VCI_Comm_PlaybackNode.il(773) : error : Undeclared identifier IL_0055
D:\Projects\VCI_Project\trunk\VCI_Comm_Win\VCI_Comm_PlaybackNode\ConfigManager.cs(37) : error : syntax error at token ':' in:     IL_0055:  br.s       IL_0057  VCI_Comm_PlaybackNode   D:\Projects\VCI_Project\trunk\VCI_Comm_Win\packages\DllExport.1.4.0\tools\net.r_eg.DllExport.targets    61  

Using detailed buildlog I can see the following errors:

8>  calling 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\ILAsm.exe' with /nologo "/out:D:\Projects\VCI_Project\trunk\VCI_Comm_Win\VCI_Comm_PlaybackNode\bin\x86\Debug\VCI_Comm_PlaybackNode.dll" "C:\Users\[...]\AppData\Local\Temp\tmp4CC9\VCI_Comm_PlaybackNode.il" /DLL "/resource=C:\Users\[...]\AppData\Local\Temp\tmp4CC9\VCI_Comm_PlaybackNode.res"  /debug   (TaskId:101)
8>  ILAsm 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\ILAsm.exe' returned gracefully. (TaskId:101)
8>D:\Projects\VCI_Project\trunk\VCI_Comm_Win\packages\DllExport.1.4.0\tools\net.r_eg.DllExport.targets(61,5): error : C:\Users\[...]\AppData\Local\Temp\tmp4CC9\VCI_Comm_PlaybackNode.il(773) : error : Undeclared identifier IL_0055
8>D:\Projects\VCI_Project\trunk\VCI_Comm_Win\packages\DllExport.1.4.0\tools\net.r_eg.DllExport.targets(61,5): error : D:\Projects\VCI_Project\trunk\VCI_Comm_Win\VCI_Comm_PlaybackNode\ConfigManager.cs(37) : error : syntax error at token ':' in:     IL_0055:  br.s       IL_0057
8>D:\Projects\VCI_Project\trunk\VCI_Comm_Win\packages\DllExport.1.4.0\tools\net.r_eg.DllExport.targets(61,5): error : 
8>     at RGiesecke.DllExport.Parsing.IlParser.RunIlTool(String installPath, String toolFileName, String requiredPaths, String workingDirectory, String settingsName, String arguments, String toolLoggingCode, String verboseLoggingCode, IDllExportNotifier notifier, Int32 timeout, Func`2 suppressErrorOutputLine) in C:\Users\[...]\Downloads\DllExport-1.4\DllExport-1.4\RGiesecke.DllExport\Parsing\IlParser.cs:line 378
8>     at RGiesecke.DllExport.Parsing.IlAsm.RunCore(CpuPlatform cpu, String fileName, String ressourceParam, String ilSuffix) in C:\Users\[...]\Downloads\DllExport-1.4\DllExport-1.4\RGiesecke.DllExport\Parsing\ILAsm.cs:line 148
8>     at RGiesecke.DllExport.Parsing.IlAsm.Run(String outputFile, String ilSuffix, CpuPlatform cpu) in C:\Users\[...]\Downloads\DllExport-1.4\DllExport-1.4\RGiesecke.DllExport\Parsing\ILAsm.cs:line 118
8>     at RGiesecke.DllExport.Parsing.IlAsm.ReassembleFile(String outputFile, String ilSuffix, CpuPlatform cpu) in C:\Users\[...]\Downloads\DllExport-1.4\DllExport-1.4\RGiesecke.DllExport\Parsing\ILAsm.cs:line 80
8>     at RGiesecke.DllExport.DllExportWeaver.reassembleFile(IlAsm ilAsm, String outputFile, String ilSuffix, CpuPlatform cpu) in C:\Users\[...]\Downloads\DllExport-1.4\DllExport-1.4\RGiesecke.DllExport\DllExportWeaver.cs:line 196
8>     at RGiesecke.DllExport.DllExportWeaver.RunIlAsm(IlAsm ilAsm) in C:\Users\[...]\Downloads\DllExport-1.4\DllExport-1.4\RGiesecke.DllExport\DllExportWeaver.cs:line 147
8>     at RGiesecke.DllExport.DllExportWeaver.Run() in C:\Users\[...]\Downloads\DllExport-1.4\DllExport-1.4\RGiesecke.DllExport\DllExportWeaver.cs:line 87
8>     at RGiesecke.DllExport.MSBuild.ExportTaskImplementation`1.Execute() in C:\Users\[...]\Downloads\DllExport-1.4\DllExport-1.4\RGiesecke.DllExport.MSBuild\RGiesecke.DllExport.MSBuild\ExportTaskImplementation.cs:line 415 (TaskId:101)
8>Done executing task "DllExportAppDomainIsolatedTask" -- FAILED. (TaskId:101)
8>Done building target "DllExportMod" in project "VCI_Comm_PlaybackNode.csproj" -- FAILED.: (TargetId:172)
8>

I have tried both DLLExport v.1.2.7 and 1.4.0. Same issue with both.
I have also tried multiple versions of Fody. No difference.

A snippet from the generated .il file:

.class private auto ansi beforefieldinit 'VCI_Comm_PlaybackNode'.'ConfigManager'
       extends ['mscorlib']'System'.'Object'
{
  .field private class 'VCI_Comm_PlaybackNode.NodeConfig'.'CustomProperties' '_custProp'
  .field private class 'VCI_Comm_PlaybackNode.NodeConfig'.'CustomProperties' '<Config>k__BackingField'
  .custom instance void ['mscorlib']'System.Diagnostics'.'DebuggerBrowsableAttribute'::.ctor(valuetype ['mscorlib']'System.Diagnostics'.'DebuggerBrowsableState') = ( 01 00 00 00 00 00 00 00 ) 
  .custom instance void ['mscorlib']'System.Runtime.CompilerServices'.'CompilerGeneratedAttribute'::.ctor() = ( 01 00 00 00 ) 
  .method public hidebysig instance bool 
          'SetupConfig'(uint32 'sessionID',
                        string 'xmlConfig') cil managed
  {
    // Code size       106 (0x6a)
    .maxstack  3
    .locals init ([0] string 'key',
             [1] class ['System.Xml']'System.Xml.Serialization'.'XmlSerializer' 'serializer',
             [2] class ['mscorlib']'System.IO'.'StringReader' 'stream',
             [3] class ['System.Xml']'System.Xml'.'XmlReader' 'reader',
             [4] bool )
    .line 17,17 : 9,10 'C:\\Projects\\VCI_Project\\trunk\\VCI_Comm_Win\\VCI_Comm_PlaybackNode\\ConfigManager.cs'
    IL_0000:  nop
    .line 18,18 : 13,44 ''
    IL_0001:  ldarga.s   'sessionID'
    IL_0003:  call       instance string ['mscorlib']'System'.'UInt32'::'ToString'()
    IL_0008:  stloc.0
    .line 19,19 : 13,74 ''
    IL_0009:  ldtoken    'VCI_Comm_PlaybackNode.NodeConfig'.'CustomProperties'
    IL_000e:  call       class ['mscorlib']'System'.'Type' ['mscorlib']'System'.'Type'::'GetTypeFromHandle'(valuetype ['mscorlib']'System'.'RuntimeTypeHandle')
    IL_0013:  newobj     instance void ['System.Xml']'System.Xml.Serialization'.'XmlSerializer'::.ctor(class ['mscorlib']'System'.'Type')
    IL_0018:  stloc.1
    .line 21,21 : 20,60 ''
    IL_0019:  ldarg.2
    IL_001a:  newobj     instance void ['mscorlib']'System.IO'.'StringReader'::.ctor(string)
    IL_001f:  stloc.2
    .line 22,22 : 20,57 ''
    .try
    {
      IL_0020:  ldloc.2
      IL_0021:  call       class ['System.Xml']'System.Xml'.'XmlReader' ['System.Xml']'System.Xml'.'XmlReader'::'Create'(class ['mscorlib']'System.IO'.'TextReader')
      IL_0026:  stloc.3
      .line 23,23 : 13,14 ''
      .try
      {
        IL_0027:  nop
        .line 24,24 : 17,79 ''
        IL_0028:  ldarg.0
        IL_0029:  ldloc.1
        IL_002a:  ldloc.3
        IL_002b:  callvirt   instance object ['System.Xml']'System.Xml.Serialization'.'XmlSerializer'::'Deserialize'(class ['System.Xml']'System.Xml'.'XmlReader')
        IL_0030:  castclass  'VCI_Comm_PlaybackNode.NodeConfig'.'CustomProperties'
        IL_0035:  stfld      class 'VCI_Comm_PlaybackNode.NodeConfig'.'CustomProperties' 'VCI_Comm_PlaybackNode'.'ConfigManager'::'_custProp'
        .line 25,25 : 13,14 ''
        IL_003a:  nop
        IL_003b:  leave.s    IL_0048

        .line 16707566,16707566 : 0,0 ''
      }  // end .try
      finally
      {
        IL_003d:  ldloc.3
        IL_003e:  brfalse.s  IL_0047

        IL_0040:  ldloc.3
        IL_0041:  callvirt   instance void ['mscorlib']'System'.'IDisposable'::'Dispose'()
        IL_0046:  nop
        IL_0047:  endfinally
        .line 16707566,16707566 : 0,0 ''
      }  // end handler
      IL_0048:  leave.s    IL_0055

      .line 16707566,16707566 : 0,0 ''
    }  // end .try
    finally
    {
      IL_004a:  ldloc.2
      IL_004b:  brfalse.s  IL_0054

      IL_004d:  ldloc.2
      IL_004e:  callvirt   instance void ['mscorlib']'System'.'IDisposable'::'Dispose'()
      IL_0053:  nop
      IL_0054:  endfinally
      .line 27,27 : 13,32 ''
    }  // end handler
    IL_0055:  ldarg.0
    IL_0056:  ldarg.0
    IL_0057:  ldfld      class 'VCI_Comm_PlaybackNode.NodeConfig'.'CustomProperties' 'VCI_Comm_PlaybackNode'.'ConfigManager'::'_custProp'
    IL_005c:  call       instance void 'VCI_Comm_PlaybackNode'.'ConfigManager'::'set_Config'(class 'VCI_Comm_PlaybackNode.NodeConfig'.'CustomProperties')
    IL_0061:  nop
    .line 29,29 : 13,25 ''
    IL_0062:  ldc.i4.1
    IL_0063:  stloc.s    
    IL_0065:  br.s       IL_0067

    .line 30,30 : 9,10 ''
    IL_0067:  ldloc.s    
    IL_0069:  ret
  } // end of method 'ConfigManager'::'SetupConfig'

The source code of the function that fails looks like this:

    internal class ConfigManager
    {
        private CustomProperties _custProp;

        public bool SetupConfig(uint sessionID, string xmlConfig)
        {
            var key = sessionID.ToString();
            var serializer = new XmlSerializer(typeof(CustomProperties));

            using (var stream = new StringReader(xmlConfig))
            using (var reader = XmlReader.Create(stream))
            {
                _custProp = (CustomProperties) serializer.Deserialize(reader);
            }

            Config = _custProp;

            return true;
        }

        public CustomProperties Config { get; set; }
    }

The failing line is "return true;" if I read the output correctly.

Best Regards
Oscar