I'm writing plugins (i.e. .Net 4 libraries with a special entry point) for a .Net framework application, but I also want to expose the functionality as self-contained CLI executable.
The current directory layout looks like this:
Directory.build.props // shared configuration, e.g. author name, project name
FooPlugin/FooPlugin.cs
Foo/FooPlugin/FooPlugin.csproj
Foo/FooLib/FooLib.cs
Foo/FooLib/FooLib.csproj
Foo/FooExe/FooExe.cs
Foo/FooExe/FooExe.csproj
Bar/BarPlugin/…
FooLib
is a .Net Standard 2.0 library with the entire functionality in FooLib.cs
, FooPlugin
is a .Net 4.8 library with the entry point for the plugin FooPlugin.cs
and FooExe
is a .Net Core executable with a CLI wrapper for FooLib
in FooExe.cs
. So far, so good.
I have two major problems with this approach:
FooPlugin
depends on several application specific Windows-only assemblies so I can't justdotnet build
from the root directory, because msbuild tries to buildFooPlugin
as well and I haven't figured out how to conditionally exclude subprojects from the solution file.Each plugin (and CLI app) has two files (
FooPlugin.dll
andFooLib.dll
/FooExe.dll
andFooLib
.dll) which in itself isn't that bad, but my users ignore
FooLib.dlland then complain.
ILMerge` looks promising, but its configuration is a lot more complicated than the entire remaining build configuration combined.
In CMake, I'd just write
add_library(FooLib STATIC FooLib.cpp)
add_library(FooPlugin SHARED FooPlugin.cpp)
target_link_libraries(FooPlugin PRIVATE FooLib)
add_executable(FooExe SHARED FooExe.cpp)
target_link_libraries(FooExe PRIVATE FooLib)
and have FooLib
merged into both FooPlugin.dll
and FooExe.exe
.
I already thought about putting symlinks to the (few) source files in FooLib
into FooPlugin
and FooExe
, but the support for symlinks on Windows isn't that good yet.
Can I define targets in msbuild to be merged into assemblies automatically?