How to F5 deploy with add-in libraries in Visual Studio?

Question

I maintain an application with some project references it depends on. Further on, there are some "add-in" projects in the same solution which aren't needed to compile the application, but are loaded at run-time. Nevertheless, the "add-in" projects are vital for the application to do its work. That is, they are mandatory add-ins.

My team shall always be able to launch the application using Visual Studio, doing an incremental build as necessary, with the add-in libraries deployed to the application.

The add-in projects don't share their output directory with the application project since the add-in projects are AnyCPU, while the application is build for the x86 and x64 platforms.

I hesitate to simply add P2P references to the add-in projects. Not having the P2P references is not only a good way to communicate the add-in character of those projects, it also helps IntelliSense to not become overwhelming.

I tried to use P2P references with ReferenceOutputAssembly set to false , but this seems to not support incremental build inside Visual Studio.

So, in presence of the above mentioned real-world constraints, how can I provide a satisfactory F5-experience?

Answer 1

Use P2P references with ReferenceOutputAssembly set to false , but consider the following pit-falls:

• As things are now with Visual Studio 2017 version 15.4.2 and earlier, the fast up to date check doesn't support this feature. Therefore, disable the check by setting the DisableFastUpToDateCheck property to true in the application project, as described in the docs . This is likely to substantially increase build time.
• Don't specify the CopyToOutputDirectory metadatum in the project reference in case the output directory of application and referred project coincide. Otherwise, this brakes the Rebuild target.

Answer 2

So, in presence of the above mentioned real-world constraints, how can I provide a satisfactory F5-experience?

If I understand you correct, I am afraid you have entered a misunderstanding. Using P2P references with ReferenceOutputAssembly set to false , Visual Studio/MSBuild will not copy that reference library to the output of reference project, but the referenced project will still be compiled.

If you do not want to compile those "add-in" projects in the same solution, but load them at run-time, you can reference the .dll file directly of those "add-in" projects. Or you can package your Library assemblies with NuGet. You can then use NuGet in Visual Studio to take care of all these references. In those case, the "add-in" projects aren't compile, but are loaded at run-time.

If you just want not copy those libraries of "add-in" projects into the output directory for reference project, you can set the property " Copy Local " of those references to false.

Update for comment:

I'd like to develop the "add-in" projects in the same solution. Do you advise against this workflow?

The simple answer is yes. If you develop the "add-in" projects in the same solution, when you make any modification in the referenced project, the reference project will be recompile, which will destroy your previous deploy. So I do not recommend develop the "add-in" projects in the same solution, you can move it to a new solution. If you still want to develop that projects in the same solution, you can refer to my previous advice "package your Library assemblies with NuGet. You can then use NuGet in Visual Studio to take care of all these references.". In this case, the previous deploy would not be destroyed When you develop add-in project.

Hope this helps.

Answer 3

Just use P2P references everywhere to make it work. That is, prefer a working build system over the cosmetics of not directly having referenced the "add-in" projects.