-1

I stumbled into a cooperation project, where the other part references an interface library of mine and deploys a self compiled MEF Plugin for our tool. I know which methods those guys are using and I want to monitor our library during the the build process, if the method signatures have been changed (just to make sure, noone checked in stuff, which should lead to another interface version and impairs the plugins loadability).

Actually, I have a console project in mind, where the signatures are somehow hardcoded and checked via reflection - but maybe there is a more elegant or simple way.

Any hint would be great.

Thanks in advance!

Monga
  • 29
  • 3

2 Answers2

1

Roslyn 2.3 introduces a feature for generating reference assemblies. That is an assembly containing only public types and members. When used together with the "deterministic" feature (=> reproducible builds), the generated reference assembly remains binary identical as long as no changes to the public interface is made (implementation changes and private/internal members don't matter).

So you can add this to your csproj:

<PropertyGroup>
  <Deterministic>true</Deterministic>
  <ProduceReferenceAssembly>true</ProduceReferenceAssembly>
</PropertyGroup>

Until VS 2017 15.5 comes out, I suggest adding <CompileUsingReferenceAssemblies>false</CompileUsingReferenceAssemblies> to all consuming projects because the IDE (e.g. "go to definition") has some problems with this feature unless you are using the "new project system" that is used for .NET Core and .NET Standard projects. (The idea would be that projects referencing the project are only rebuilt if the public interface changes - this speeds up incremental build for large solutions when only implementations change).

These changes will create a ref folder in your output. You can then check if the checksum of the assmbly in there matches a known cheksum on each build.

Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
  • Ah, okay, that is an interesting approach for the whole assembly. Unfortunately, there is exactly one interface.dll with hundreds of types - the deterministic ref assembly option would reproduce a new assembly with a new checksum everytime we add other interfaces, doesn't it? – Monga Aug 26 '17 at 07:10
  • Yes that is true. In that case this option won't work for you. I'll leave the answer up though in case it helps someone – Martin Ullrich Aug 26 '17 at 07:40
0

I ended up creating a small console application with a try catch block, using the same interface dll and the same objects as the project partner does - compiled with the last released interface library. During execution it falls into the catch branch if the signatures got invalid (discovered by the normal .NET processes) - then the exitcode is raised with -1.

Doing all this in the post build processes, cathcing the exit code as discribed this article and breaking build automatically.

Not very happy with that solution, but got it working ... Further ideas still wanted :-)

Monga
  • 29
  • 3