diff --git a/DllExports.MSBuild/DllExports.MSBuild.csproj b/DllExports.MSBuild/DllExports.MSBuild.csproj index 8773856..6ff7db4 100644 --- a/DllExports.MSBuild/DllExports.MSBuild.csproj +++ b/DllExports.MSBuild/DllExports.MSBuild.csproj @@ -17,13 +17,9 @@ Unlike other libraries that rely on a wacky series of external dependencies, DllExports has everything it needs to do its job built in. -DllExports is entirely driven by its MSBuild task, and provides a number of knobs you can adjust to customize the resulting assemblies, -including converting AnyCPU assemblies into both x86 and x64 outputs. +DllExports is entirely driven by its MSBuild task, and provides a number of knobs you can adjust to customize the resulting assemblies, including converting AnyCPU assemblies into both x86 and x64 outputs. -Note that when using IDA Pro, load the file as "Portable executable for 80386 (PE)" instead of "Microsoft.NET assembly" in order to see the exports. - -In order to be able to debug your exports in Visual Studio you must be targeting .NET Framework. .NET Standard exports work but you can't debug them. -.NET Core applications can't truly have unmanaged exports as you can't use mscoree to load their runtime. Consider using a library such as DNNE for proper .NET Core support. +In order to be able to debug your exports in Visual Studio you must be targeting .NET Framework and be using Visual Studio 2019 or newer. .NET Standard exports work but you can't debug them. .NET Core applications can't truly have unmanaged exports as you can't use mscoree to load their runtime. Consider using a library such as DNNE for proper .NET Core support. diff --git a/DllExports.MSBuild/build/DllExports.targets b/DllExports.MSBuild/build/DllExports.targets index 287837c..b0d3afc 100644 --- a/DllExports.MSBuild/build/DllExports.targets +++ b/DllExports.MSBuild/build/DllExports.targets @@ -24,6 +24,12 @@ false + + + ``` 2. Add a package reference, with `Private = False` so DllExports does not get emitted to your output directory ```xml - ..\..\packages\DllExports.0.1.0\lib\netstandard2.0\DllExports.dll + ..\..\packages\DllExports.0.1.1\lib\netstandard2.0\DllExports.dll False ``` 3. Import the `targets` at the end of the file and add a `Target` to warn when NuGet packages have not been restored ```xml - + This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}. - + ``` @@ -92,8 +90,12 @@ Adjust the version number in the above snippets as necessary. The [NetFramework] ## Tips +* You cannot use projects that generate Portable PDB files together with DllExports in Visual Studio 2017. Something about the modifications that dnlib (which DllExports uses internally) makes upsets Visual Studio when it goes to load +the modified PDB file, and crashes the entire program. As such, DllExports will throw an error if it detects you are using portable/embedded PDB files in Visual Studio 2017, and recommend you use `full` instead. +Newer versions of Visual Studio do not have this issue. It's not clear whether Visual Studio 2017 or dnlib is failing to follow the Portable PDB file format properly. Legacy style projects default to *full* PDB files, while SDK style projects +default to *portable*. * Don't use types types external to your assembly or the CLR in the method signature of your exports. e.g. do not use the `HRESULT` type from [ClrDebug](https://github.com/lordmilko/ClrDebug). The runtime is not in a position to load -external assemblies when your export is called. You can however use types defined in the same assembly that your export is defined in +external assemblies when your export is called. You can however use types defined in the same assembly that your export is defined in. * Once an external assembly has been loaded, it is safe to use types in external external assemblies in subsequently called exports * You can force architecture specific files to be placed in an architecture specific subdirectory by setting `DllExportsArchitectureNameFormat` to something like `{arch}\{name}.{arch}` i.e. `Foo.dll` compiled for AMD64 will go to `x64\Foo.x64.dll` * When multi-targeting, you can conditionally generate unmanaged exports for compatible assemblies as follows diff --git a/Version.props b/Version.props index 7f45544..52d45fc 100644 --- a/Version.props +++ b/Version.props @@ -1,8 +1,8 @@ - 0.1.0 + 0.1.1 0.1.0.0 - 0.1.0.0 - 0.1.0 + 0.1.1.0 + 0.1.1