Question regarding depending on the `DllExported` dlls on another project

So, currently, I have a .NET Core project on my solution called Hooks where I export some methods to deal with Windows Hooks. And I need to depend on that project from another project on the same solution.

Is it possible to, without using the Post build actions, make the project copy the DLLs in the x86 and x64 folders to the output directory of the projects that depend on it?

[3F]

It would be nice to have it inside

I think we can try to review this suggestion as optional Post-Processing feature “as is” like for a new #146 where built Pre-Processing.

But as I mentioned:

1. Default tasks such ResolveAssemblyReferences + ReferenceCopyLocalPaths (and related) will be really difficult for anything to base on it.
2. Implementing a new or some modifications of the default logic is a big task for this really tiny thing. Let me know if msbuild provides another suitable tasks for this issue.
3. The project itself does not know where it will be used which is logically correct for what purpose ResolveAssemblyReferences was initially designed.
4. Historically the solution-scope did not have (and partially still hasn’t) a clear specification or even public implementation in all visualstudio-family products. This is one of the reasons why MvsSln was appeared together with vsSBE in 2013.

MvsSln, however, already implements the dependency graph in analyzed solution (I know, because I was personally implementing this in the past). But as I voiced this task is complicated by the user context where both visualstudio and msbuild can provide only a separate project-or-like environment.

And if we’re talking about a normal implementation from outside, then we also need to control the build state for the whole solution scope from a restricted project scope. Otherwise we cannot be sure of anything since modules or even paths can be also modified later for some reason from other tools, and so on.

But we can do it easier if we’ll try only to copy our artifacts by paths from evaluated properties at the moment of processing DllExport, again, without guarantees of anything.

This is most simple solution for this issue, but it cannot be safe for all user cases as you can see. However, this is perfectly fits for some additional option for Post-Processing feature.

[3F]

I’ll try to review this for 1.7.1.

By the way, the use of the mentioned graph is currently complicated by this issue: https://github.com/3F/MvsSln/issues/25 Let me know if anyone knows something about related changes in Visual Studio 16.x !