2

I have solution TestName.sln(Class Library) which is built on Target Framework .Net Standard 2.0.

TestName.sln includes some dependencies 1,2 (includes its own packages), 3, from NuGet, look like a tree.

When I packed TestName.sln I got TestName.dll and I will want to use TestName.dll in SSIS 2017.

I added TestName.dll to Global Assembly Cache without any problem.

But when I try to use TestName.dll I see the classes only from TestName.sln and don't see the classes and can't use dependencies 1,2,3,4 which I included in TestName.sln.

What will I need to do in order to have all dependencies in one .dll file if possible? Or how I should link all dependencies to one for use in SSIS 2017?

billinkc
  • 59,250
  • 9
  • 102
  • 159
Denys
  • 53
  • 6
  • Based on my poor comprehension of https://stackoverflow.com/questions/45291737/referencing-between-netstandard-and-net-framework I don't know that a Framework assembly can reference a Standard assembly. Answering via Comment because I'm punching above my weight class on this stuff – billinkc Jan 25 '23 at 16:56
  • 1
    Have you tried using ILMerge? It can meet your needs. You can use it to centralize multiple dependencies into a single assembly. – wenbingeng-MSFT Jan 26 '23 at 06:10
  • @wenbingeng-MSFT I didn`t know about ILMerge. I will try it. Thanks. – Denys Jan 26 '23 at 09:14
  • @wenbingeng-MSFT Yes, ILMerge has helped me :) Thank you. – Denys Jan 31 '23 at 12:11

1 Answers1

1

You can use ILMerge to centralize multiple dependencies into a single assembly.

Firstly, to install ILMerge.MSBuild.Tasks package from nuget.

Secondly, edit the *.csproj file of the project that you want to merge by adding the code below.

  <UsingTask TaskName="ILMerge.MSBuild.Tasks.ILMerge" AssemblyFile="$(SolutionDir)\packages\ILMerge.MSBuild.Tasks.1.0.0.3\tools\ILMerge.MSBuild.Tasks.dll" />
  <Target Name="AfterBuild">
    <ItemGroup>
      <MergeAsm Include="$(OutputPath)$(TargetFileName)" />
      <MergeAsm Include="$(OutputPath)LIB1_To_MERGE.dll" />
      <MergeAsm Include="$(OutputPath)LIB2_To_MERGE.dll" />
    </ItemGroup>
    <PropertyGroup>
      <MergedAssembly>$(ProjectDir)$(OutDir)MERGED_ASSEMBLY_NAME.exe</MergedAssembly>
    </PropertyGroup>
    <Message Text="ILMerge @(MergeAsm) -&gt; $(MergedAssembly)" Importance="high" />
    <ILMerge InputAssemblies="@(MergeAsm)" OutputFile="$(MergedAssembly)" TargetKind="SameAsPrimaryAssembly" />
  </Target>

Lastly, build your project as usual.

wenbingeng-MSFT
  • 1,546
  • 1
  • 1
  • 8
  • The first time I used ILMerge using command ".nuget\packages\ilmerge\3.0.40\tools\net452>ilmerge /out: Avro.Api.dll Avro.dll Apache.dll" and all was great. Now I`m want trying use your method but can`t understand why it is not working – Denys Feb 06 '23 at 14:13
  • – Denys Feb 06 '23 at 14:13
  • $(ProjectDir)$(OutDir)MERGED_ASSEMBLY_NAME.dll – Denys Feb 06 '23 at 14:14
  • @Denys This method is more demanding on the environment than the method you use. Do you have a refactoring project at the end? – wenbingeng-MSFT Feb 07 '23 at 01:16
  • I created a simple class library project `using Newtonsoft.Json.Linq; namespace ClassLibrary1 { public class Class1 { } }` and added the reference Newtonsoft.Json.Linq for testing how I can use ILMerge.MSBuild.Tasks in a big projects. – Denys Feb 07 '23 at 09:36
  • [ILMerge](https://github.com/dotnet/ILMerge) I used this and it is working. Has ILMerge.MSBuild.Tasks.ILMerge some differences from ILMerge? – Denys Feb 07 '23 at 13:01
  • 1
    @Denys The nuget package version of some project tools may not be updated in time or may be compatible with the new version of .net. This is more common, at this time we usually need to replace the lower. Net version. But if your project has already progressed then I don't recommend you to do this. And the ILmerge you are using is correct. – wenbingeng-MSFT Feb 08 '23 at 01:16