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

[NickAcPT]

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]

without using the Post build actions

Yes. Try this https://github.com/3F/vsSolutionBuildEvent

It can especially help if, for example, you want to avoid any changes to the projects files (etc).

Scripting is available through various engines (msbuild targets, C#, or SobaScript and E-MSBuild, etc).
IDE and CI support of course.

Or you can interact more with Visual Studio on the fly via https://github.com/3F/vsCommandEvent

[NickAcPT]

But that will require an extension to be installed.
It would be nice to have it inside DllExport somehow so that things work everywhere.

[3F]

But that will require an extension to be installed.

Only if you need support IDE. For CIM it's automated through nuget and does not require anything from user. This repo is also configured through CIM version.

It would be nice to have it inside DllExport somehow so that things work everywhere.

Actually we can try through https://github.com/3F/MvsSln extend support for projects that depends on project where DllExport is used. But in fact this task is not trivial and:

• Firstly, it will be limited to just a single solution (where projects are activated for build) because we definitely can know only this and nothing concrete from outside.
• And secondly, we need implement a decent piece of logic for managing this through project-scope. Because solution-scope is not available for build through vs/msbuild if we're talking about default user's tools/actions with projects.

You can also open PR to consider a better way together.

Thus, I recommend to use at least vsSolutionBuildEvent, or alternatives (if you do not want to use my mentioned projects for some reason)

[NickAcPT]

Oh, I see. I'll use that for now 👍
Thanks a lot.

[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: 3F/MvsSln#25
Let me know if anyone knows something about related changes in Visual Studio 16.x !