Embedding the output from one project into another within the same solution

Question

_{Monday, October 23, 2017 8:15 PM}

I have two C# projects in a solution, is there any way to use macros to either leveraged a referenced project or a bettter way altogether to embed a dll from one project into another? Currently, I use a build event to copy the dll into a folder within the embedding project, then reference the static location in the resource file. The build event resembles

copy /Y $(SolutionDir)ProjectA\bin\$(ConfigurationName)\ProjectA.dll $(ProjectDir)Resources\

Regardless, I am still hardcoding the path despite ProjectA being referenced in the project with the above build event.

Is there a better way to do this? Ultimately, I need access to the binary contents of ProjectA's $(TargetPath) no matter the build configuration at runtime in ProjectB's resource manager, no matter its build configuration?

All replies (5)

_{Wednesday, October 25, 2017 11:44 AM ✅Answered}

Thanks for your reply. You can use wildcard to get that binary resource in PorjectB, but we could not use wildcard in the PropertyGroup, we need to convert PropertyGroup to item first. So we could change your build-event to a copy task with wildcard:

  <ItemGroup>
    <MySourceFiles Include="$(SolutionDir)ProjectA\bin\**\ProjectA.dll"/>
  </ItemGroup>

  <Target Name="CopyTest" AfterTargets="Build">
    <Copy
            SourceFiles="@(MySourceFiles)"
            DestinationFolder="$(ProjectDir)Resources\"
        />

  </Target>

In this case, you can get that binary resource in PorjectB no matter the configuration.

MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected].

_{Monday, October 23, 2017 10:46 PM}

Hello,

I'm moving your question to the Visual Studio forum which is a better place for this question.

Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
VB Forums - moderator

_{Tuesday, October 24, 2017 8:20 AM}

Hi Ritmo2k,

>>>Is there a better way to do this? Ultimately, I need access to the binary contents of ProjectA's $(TargetPath) no matter the build configuration at runtime in ProjectB's resource manager, no matter its build configuration?

Since those two projects in the same solution and you want to embed a dll from one project into another, you can try to use project-to-project reference, that means add ProjectA reference to another project, let say it PorjectB: Right click Project B-> Add->Reference->Select Project A.

If you do not want to use project-to-project reference, I would like provide you a workaround to you. You can add similar post-build event for project A:

copy /Y $(TargetPath) $(SolutionDir)\ProjectB\Resources\

In this case, you can copy the binary contents of ProjectA's to the static location in the resource file, no matterits build configuration.

Hope this helps.

 ****

MSDN Community Support Please remember to click Mark as Answer. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected].

_{Tuesday, October 24, 2017 12:20 PM}

Hi, ProjectB does reference ProjectA, it uses the namespaces contained in it. ProjectB however also needs to embed ProjectA's dll for other runtime uses. My hope was there was a better way to get that binary resource in PorjectB no matter the configuration etc...

_{Wednesday, October 25, 2017 8:15 PM}

Thanks that was an improvement. I noticed a minor VS anomaly when you change the content tag to a named tag, it no longer nests the item in the tree within the hierarchy, but in the root instead.