Question regarding depending on the DllExported dlls on another project
#144
Comments
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). Or you can interact more with Visual Studio on the fly via https://github.com/3F/vsCommandEvent |
|
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.
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:
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) |
|
Oh, I see. I'll use that for now 👍 |
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:
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. |
|
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 |
* MvsSln up to rev `9c39498` due to 3F/MvsSln#25 Part of #144 * Post-Processing #148: Implemented backend logic with configurable environment: Format: $(SolutionPath);$(MSBuildThisFileFullPath);...populated property names...;.... ``` <Target Name="DllExportPostProc"> <!-- Now we can access the following properties and items: $(DllExport) - version $(DllExportSln) - full path to .sln which controls current project $(DllExportPrj) - full path to current project where processed .NET DllExport @(DllExportDirX64) - $(TargetDir)x64\*.* @(DllExportDirX86) - $(TargetDir)x86\*.* @(DllExportDirBefore) - $(TargetDir)Before\*.* @(DllExportDirAfter) - $(TargetDir)After\*.* @(DllExportDependents + populated property name) - each populated properties from DllExportInvokedPoint, e.g. DllExportDependentsTargetDir @(DllExportDependencies + populated property name) - each populated properties from DllExportInvokedPoint, e.g. DllExportDependenciesTargetDir --> </Target> ``` * Post-Proc. Added support of external .net.dllexport.targets * PostProc usage has been moved into ExportTaskImplementation * Fixed MSB4094 when using the same properties +Checking the existence of our entry point * `DllExportInvokedPoint` renamed as `DllExportProcEnv` * Basic GUI support for predefined options in Post-Proc feature That is, *! Some Post-Proc features are not yet available in GUI. But you can already configure it with msbuild. * cleanup * Updated data in SimpleConfFormater.Parse() +PostProc +PreProc * MvsSln up to rev `838fab00dd` /? #148 (comment) * MvsSln up to rev `e07c5806dd`: +`ProjectReference` support without obsolete projectguid * Updated MvsSln 2.5.2 * Added multiple destination support via derivative targets: #148 (comment) * +`DllExportSeqDependents...` Includes sequential referencing through other projects
* NEW: Pre-Processing feature. PR #146. Related issue #40 Official ILMerge support; https://github.com/dotnet/ILMerge Quick integration with Conari for most easy access to unmanaged features; https://github.com/3F/Conari +Other related tools and assembly manipulations. Manual configuring: #40 (comment) * NEW: Post-Processing. PR #148. Continues direction of Pre-Processing feature. PR #146 Related issue #144 Explanation and details: https://ko-fi.com/Blog/Post/ILMerge---Conari---Debug-information---DllExport-=-O5O61MV8A 1.7.1 Provides only basic GUI support for predefined options. Thus, *! Some Post-Proc features are not yet available in GUI. But you can already configure it with msbuild: ``` <Target Name="DllExportPostProc"> <!-- After activation, you can access the following properties and items: $(DllExport) - version $(DllExportSln) - full path to .sln which controls current project $(DllExportPrj) - full path to current project where processed .NET DllExport @(DllExportDirX64) - $(TargetDir)x64\*.* @(DllExportDirX86) - $(TargetDir)x86\*.* @(DllExportDirBefore) - $(TargetDir)Before\*.* @(DllExportDirAfter) - $(TargetDir)After\*.* @(DllExportDependents + populated property name) - each populated properties from DllExportProcEnv, e.g. DllExportDependentsTargetDir @(DllExportDependencies + populated property name) - each populated properties from DllExportProcEnv, e.g. DllExportDependenciesTargetDir @(DllExportSeqDependents + populated property name) - each populated properties from DllExportProcEnv, e.g. DllExportSeqDependentsTargetDir --> </Target> ``` #148 (comment) * NEW: Optional copying of intermediate files + x86+x64 directories into output for projects that dependent on projects where used DllExport. Issue #144. Including sequential referencing through other projects: #148 (comment) * FIXED: Fixed #140 ... failed to create safe SSL/TLS context. * FIXED: Pack of fixes for .net.dllexport.targets. PR #147. * Fixed "Cannot modify an evaluated object originating in an imported file". * Fixed possible duplication in .net.dllexport.targets when configuring. * Adds removing TargetsFile if not used. * Fixed possible loss of settings in .targets when configuring. * FIXED: Fixed #143 'Microsoft.NET.Sdk' specified could not be found. * FIXED: A multiple empty `<PropertyGroup />` in project files during new configuration. * CHANGED: Wizard. Dropped support for ssl3 + tls1.0 + tls1.1 * CHANGED: Wizard. Simplified notification for stable versions. * CHANGED: Manager. Access to hMSBuild tool (packed) via `-hMSBuild` key. https://github.com/3F/hMSBuild Since it uses packed version (while GetNuTool is integrated inside), you need use -dxp-version to control specific version. * CHANGED: Updated Cecil 0.11.2 https://github.com/jbevain/cecil/releases/tag/0.11.2 * CHANGED: Updated MvsSln 2.5.2 https://github.com/3F/MvsSln/releases/tag/2.5.2
So, currently, I have a .NET Core project on my solution called
Hookswhere 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 buildactions, make the project copy the DLLs in thex86andx64folders to the output directory of the projects that depend on it?The text was updated successfully, but these errors were encountered: