Quantcast
Channel: ILMerge MSBuild task NuGet package
Viewing all 48 articles
Browse latest View live

Created Unassigned: ILMerge.Merge: ERROR!!: Duplicate type [11]

$
0
0
I try to merge all DLL of my library.
When I build, I get this error :
ILMerge.Merge: ERROR!!: Duplicate type 'System.Net.Http.HttpRequestMessageExtensions' found in
assembly 'System.Web.Http.SelfHost'. Do you want to use the /alllowDup option?

If I well read I should use allowDup, but I can't how to do on the web ?

I tried <ILMergeAllowDuplicateType>true</ILMergeAllowDuplicateType>, but doesn't change any thinks.

Edited Unassigned: ILMerge.Merge: ERROR!!: Duplicate type [11]

$
0
0
I try to merge all DLL of my library.
When I build, I get this error :
ILMerge.Merge: ERROR!!: Duplicate type 'SolidWorks.Interop.sldworks.DSldWorksEvents' found in assembly 'Solidworks.Helper'. Do you want to use the /alllowDup option?

If I well read I should use allowDup, but I can't how to do on the web ?

I tried <ILMergeAllowDuplicateType>true</ILMergeAllowDuplicateType>, but doesn't change any thinks.

Edited Unassigned: ILMerge.Merge: ERROR!!: Duplicate type [11]

$
0
0
I try to merge all DLL of my library.
When I build, I get this error :
ILMerge.Merge: ERROR!!: Duplicate type 'SolidWorks.Interop.sldworks.DSldWorksEvents' found in assembly 'Solidworks.Helper'. Do you want to use the /alllowDup option?

If I well read I should use allowDup, but I can't how to do on the web ?

I tried <ILMergeAllowDuplicateType>true</ILMergeAllowDuplicateType>, but doesn't change any thinks.

UPDATE:
You can forgot this issue. The problem was with the DLL...

Commented Unassigned: ILMerge.Merge: ERROR!!: Duplicate type [11]

$
0
0
I try to merge all DLL of my library.
When I build, I get this error :
ILMerge.Merge: ERROR!!: Duplicate type 'SolidWorks.Interop.sldworks.DSldWorksEvents' found in assembly 'Solidworks.Helper'. Do you want to use the /alllowDup option?

If I well read I should use allowDup, but I can't how to do on the web ?

I tried <ILMergeAllowDuplicateType>true</ILMergeAllowDuplicateType>, but doesn't change any thinks.

UPDATE:
You can forgot this issue. The problem was with the DLL...
Comments: I am seeing this same issue, and it doesn't appear to support updates to the properties file. I am using Web API in my project causing duplicate types for System.Net.Http.HttpRequestMessageExtensions. error : ILMerge.Merge: ERROR!!: Duplicate type 'System.Net.Http.HttpRequestMessageExtensions' found in assembly 'System.Web.Http'. Do you want to use the /alllowDup option? I go to the ILMerge.props file, and I modify the ILMergeAllowDuplicateType setting in the property group. It appears from reading the Microsoft documentation for the /allowDup option that I should list the type names in that setting. E.g. ``` <ILMergeAllowDuplicateType>System.Net.Http.HttpRequestMessageExtensions</ILMergeAllowDuplicateType> ``` It doesn't appear to affect the output in any way. Should the name of that property be ILMergeAllowDuplicateTypes? Should I specify a list in there?

Commented Unassigned: ILMerge.Merge: ERROR!!: Duplicate type [11]

$
0
0
I try to merge all DLL of my library.
When I build, I get this error :
ILMerge.Merge: ERROR!!: Duplicate type 'SolidWorks.Interop.sldworks.DSldWorksEvents' found in assembly 'Solidworks.Helper'. Do you want to use the /alllowDup option?

If I well read I should use allowDup, but I can't how to do on the web ?

I tried <ILMergeAllowDuplicateType>true</ILMergeAllowDuplicateType>, but doesn't change any thinks.

UPDATE:
You can forgot this issue. The problem was with the DLL...
Comments: Hi, we had the same problem. We found the solution in the source code: ``` if (!string.IsNullOrEmpty(this.AllowDuplicateType)) { if (this.AllowDuplicateType == "*") { merger.AllowDuplicateType(null); } else { foreach (string typeName in this.AllowDuplicateType.Split(',')) { merger.AllowDuplicateType(typeName); } } } ``` so the working value for us: ``` <ILMergeAllowDuplicateType>*</ILMergeAllowDuplicateType> ```

New Post: ILMerge.exe not found

$
0
0
I'l getting this error on 1.0.5, and it doesn't matter which ILMerge package I update to.

1>C:\Users\Jahmai.nuget\packages\MSBuild.ILMerge.Task\1.0.5\build\MSBuild.ILMerge.Task.targets(87,5): error MSB4018: The "MSBuild.ILMerge.Task" task failed unexpectedly.
1>C:\Users\Jahmai.nuget\packages\MSBuild.ILMerge.Task\1.0.5\build\MSBuild.ILMerge.Task.targets(87,5): error MSB4018: System.IO.FileNotFoundException: Cannot find ILMerge executable.
1>C:\Users\Jahmai.nuget\packages\MSBuild.ILMerge.Task\1.0.5\build\MSBuild.ILMerge.Task.targets(87,5): error MSB4018: at MSBuild.ILMerge.Task.LoadILMerge()
1>C:\Users\Jahmai.nuget\packages\MSBuild.ILMerge.Task\1.0.5\build\MSBuild.ILMerge.Task.targets(87,5): error MSB4018: at MSBuild.ILMerge.Task.Execute()
1>C:\Users\Jahmai.nuget\packages\MSBuild.ILMerge.Task\1.0.5\build\MSBuild.ILMerge.Task.targets(87,5): error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
1>C:\Users\Jahmai.nuget\packages\MSBuild.ILMerge.Task\1.0.5\build\MSBuild.ILMerge.Task.targets(87,5): error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()

I'm referencing them on a netstandard project if that makes any difference.

New Post: ILMerge.exe not found

$
0
0
I think this is because nuget created the package in:

C:\Users\Jahmai\.nuget\packages\ilmerge\2.13.307

And the build task is expecting:

C:\Users\Jahmai\.nuget\packages\ilmerge.2.13.307

New Post: Add function to manually specific additional merge modules

$
0
0
In project.json, nuget doesn't add <Reference>'s to the .csproj anymore.
That means that ILMerge build task can't pick it up.
There is also no "Copy Local" configuration for such nuget references.

So if you have a handful of nuget references, and you want to ILMerge a couple, there is currently no way to tell the ILMerge build task to do that.

It would be good if we could specify a file list (ILMergeAdditionalMergedAssemblies maybe) that is incorporated into the task.

New Post: Add function to manually specific additional merge modules

$
0
0
Frankly, I'm not going to spend time or effort on trying to support project.json or anything else beyond 4.5.2 or so. When Microsoft finally makes its mind about where it's going (right now MS is busily walking in circles), I'll think about it, if it's still relevant. After the Silverlight debacle (and deprecated WCF and WPF etc etc) I won't ever think about anything MS that wasn't stable for at least 3 years. If nothing will ever be again (seems like that now), I'll switch to Java - I'm an enterprise developer, not a buzzword-loving script kiddy, after all, I need something that still works and is supportable 10 years from now.

On the topic, if you have to explicitly specify the merge list, why don't just use a post-build step explicitly running ILMerge?

New Post: Could not abel to build WPF project

$
0
0
I am getting following error.

Severity Code Description Project File Line Suppression State
Error The item "*****\packages\LiteDB.3.0.0-beta3\lib\net35\LiteDB.dll" in item list "ReferencePath" does not define a value for metadata "CopyLocal". In order to use this metadata, either qualify it by specifying %(ReferencePath.CopyLocal), or ensure that all items in this list define a value for this metadata. *****\packages\MSBuild.ILMerge.Task.1.0.5\build\MSBuild.ILMerge.Task.targets 35

WPF project is not working where as console application is working fine

Created Unassigned: Code Analysis & ROSLYN Run on All Merged Assemblies [12]

$
0
0
It seems that in Visual Studio 2015, Code Analysis and ROSLYN run on the merged assemblies instead of the original assembly only. Is there a way to prevent this, i.e. get CA/ROSLYN to only run on the original assembly.

Created Unassigned: Please support NuGet v3 and v4 [13]

$
0
0
Please support NuGet v3 (traditional .NET Framework .csproj + project.json) and NuGet v4 (the new CPS .csproj with PackageReference).

The main difference is that all NuGet packages are put in `%home%\.nuget\packages` rather than a solution packages folder. Currently with nuGet v3 you get:

> 1>C:\Users\jmusser\.nuget\packages\msbuild.ilmerge.task\1.0.5\build\MSBuild.ILMerge.Task.targets(87,5): error : Specified merge order file 'ILMergeOrder.txt' doesn't exist.
1>C:\Users\jmusser\.nuget\packages\msbuild.ilmerge.task\1.0.5\build\MSBuild.ILMerge.Task.targets(87,5): error MSB4018: The "MSBuild.ILMerge.Task" task failed unexpectedly.
1>C:\Users\jmusser\.nuget\packages\msbuild.ilmerge.task\1.0.5\build\MSBuild.ILMerge.Task.targets(87,5): error MSB4018: System.IO.FileNotFoundException: Cannot find ILMerge executable.
1>C:\Users\jmusser\.nuget\packages\msbuild.ilmerge.task\1.0.5\build\MSBuild.ILMerge.Task.targets(87,5): error MSB4018: at MSBuild.ILMerge.Task.LoadILMerge()
1>C:\Users\jmusser\.nuget\packages\msbuild.ilmerge.task\1.0.5\build\MSBuild.ILMerge.Task.targets(87,5): error MSB4018: at MSBuild.ILMerge.Task.Execute()
1>C:\Users\jmusser\.nuget\packages\msbuild.ilmerge.task\1.0.5\build\MSBuild.ILMerge.Task.targets(87,5): error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
1>C:\Users\jmusser\.nuget\packages\msbuild.ilmerge.task\1.0.5\build\MSBuild.ILMerge.Task.targets(87,5): error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()

Created Unassigned: UnionMerge gets wrong value set [14]

$
0
0
I just adapted the `ILMergeUnionMerge` element in _ILMerge.props_:

```xml
<!-- Types with the same name are all merged into a single type in the target assembly -->
<ILMergeUnionMerge>True</ILMergeUnionMerge>
```

Unfortunately, this does not work, due to `UnionMerge` attribute is set to `$(ILUnionMerge)`, which is non-existant in _MSBuild.ILMerge.Task.targets_.

Replacing the assignment with `UnionMerge="$(ILMergeUnionMerge)"`, everything works as expected.

New Post: Any Plans to Move this to GitHub

$
0
0
Alexander, any plans to move this repo to Github now that Codeplex is shutting it's doors?

Created Unassigned: When I build my WPF app I get "CopyLocal" error [15]

$
0
0
I have MSBUILD.ILMERGE.TASK installed in my wpf application. When I build the application I get this error:

The item "C:\Users....\packages\EntityFramework.6.1.3\lib\net45\EntityFramewrok.dll" in item list "ReferencePath" does not define a value for metadata "CopyLocal".

When I select the reference for EntityFramework.dll the CopyLocal flag is true. Why am I getting this error and how do I fix it?

Created Unassigned: Bug: Directory structure of content files is lost [16]

$
0
0
The included build target script flattens the directory structure of content files.

__Example content files__ (Build Action: Content; Copy if newer):
* \Command\luatest.lua
* \ModInfo.xml

__Extract of the build log:__
```
1>Done executing task "MSBuild.ILMerge.Task".
2>Using "Copy" task from assembly "Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
3>Task "Copy"
4> Copying file from "ModInfo.xml" to "bin\Debug\ModInfo.xml".
5> Copying file from "Commands\luatest.lua" to "bin\Debug\luatest.lua".
6>Done executing task "Copy".
```

See line 6: "luatest.lua" is losing it's directory "Commands".

Given that projects often contain a LOT of deeply structured content files and folders (e.g. html, css, images, js, ...), this makes the build task unusable for such projects.

__Reason:__
The Copy task does not keep directory structure if used like this.

```
<Copy SourceFiles="@(LocalContentFiles)" DestinationFolder="$(OutputPath)" />
```

__Suggested Fix:__

The documentation of the Copy task contains an example at the end on how to use it to keep directory structure intact. Adjust the target file accordingly:

```
The following example demonstrates how to do a recursive copy.
This project copies all of the files recursively from c:\MySourceTree
into c:\MyDestinationTree, while maintaining the directory structure.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<MySourceFiles Include="c:\MySourceTree\**\*.*"/>
</ItemGroup>

<Target Name="CopyFiles">
<Copy
SourceFiles="@(MySourceFiles)"
DestinationFiles="@(MySourceFiles->'c:\MyDestinationTree\%(RecursiveDir)%(Filename)%(Extension)')"
/>
</Target>
</Project>
```
https://msdn.microsoft.com/en-us/library/3e54c37h.aspx


Edited Unassigned: Bug: Directory structure of content files is lost [16]

$
0
0
The included build target script flattens the directory structure of content files.

__Example content files__ (Build Action: Content; Copy if newer):
* \Command\luatest.lua
* \ModInfo.xml

__Extract of the build log:__
```
1>Done executing task "MSBuild.ILMerge.Task".
2>Using "Copy" task from assembly "Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
3>Task "Copy"
4> Copying file from "ModInfo.xml" to "bin\Debug\ModInfo.xml".
5> Copying file from "Commands\luatest.lua" to "bin\Debug\luatest.lua".
6>Done executing task "Copy".
```

See line 5: "luatest.lua" is losing it's directory "Commands".

Given that projects often contain a LOT of deeply structured content files and folders (e.g. html, css, images, js, ...), this makes the build task unusable for such projects.

__Reason:__
The Copy task does not keep directory structure if used like this.

```
<Copy SourceFiles="@(LocalContentFiles)" DestinationFolder="$(OutputPath)" />
```

__Suggested Fix:__

The documentation of the Copy task contains an example at the end on how to use it to keep directory structure intact. Adjust the target file accordingly:

```
The following example demonstrates how to do a recursive copy.
This project copies all of the files recursively from c:\MySourceTree
into c:\MyDestinationTree, while maintaining the directory structure.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<MySourceFiles Include="c:\MySourceTree\**\*.*"/>
</ItemGroup>

<Target Name="CopyFiles">
<Copy
SourceFiles="@(MySourceFiles)"
DestinationFiles="@(MySourceFiles->'c:\MyDestinationTree\%(RecursiveDir)%(Filename)%(Extension)')"
/>
</Target>
</Project>
```
https://msdn.microsoft.com/en-us/library/3e54c37h.aspx


Created Unassigned: Configure Output assembly name [17]

$
0
0
Hi.
Is there a way to keep an initial assembly unmerged with its initial name, and the merged one as additional with configured name?

Example of output folder is:
assembly1.dll
assembly2.dll

They both will be merged to assembly1.dll automatically.

Now I am having problems in Test projects which references project for assembly1 (but assembly is already merged and contains types from assembly2)
The test project references also assembly2 project which brings confusion for the compiler in the Test solution

It would be great if initial assemblies (the main assembly) could stay as they are, and the final, merged one could be stored under different name (if configured so)
Or maybe there is already such a possibility?

Ps. The project is great and works as a charm, but there is no way to work with Unit Testing after merging

Edited Unassigned: Configure Output assembly name [17]

$
0
0
Hi.
Is there a way to keep an initial assembly unmerged with its initial name, and the merged one as additional with configured name (using OutputFile property from the original IL Merge)?

Example of output folder is:
assembly1.dll
assembly2.dll

They both will be merged to assembly1.dll automatically.

Now I am having problems in Test projects which references project for assembly1 (but assembly is already merged and contains types from assembly2)
The test project references also assembly2 project which brings confusion for the compiler in the Test solution

It would be great if initial assemblies (the main assembly) could stay as they are, and the final, merged one could be stored under different name (if configured so)
Or maybe there is already such a possibility?

Ps. The project is great and works as a charm, but there is no way to work with Unit Testing after merging

Commented Unassigned: Bug: Directory structure of content files is lost [16]

$
0
0
The included build target script flattens the directory structure of content files.

__Example content files__ (Build Action: Content; Copy if newer):
* \Command\luatest.lua
* \ModInfo.xml

__Extract of the build log:__
```
1>Done executing task "MSBuild.ILMerge.Task".
2>Using "Copy" task from assembly "Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
3>Task "Copy"
4> Copying file from "ModInfo.xml" to "bin\Debug\ModInfo.xml".
5> Copying file from "Commands\luatest.lua" to "bin\Debug\luatest.lua".
6>Done executing task "Copy".
```

See line 5: "luatest.lua" is losing it's directory "Commands".

Given that projects often contain a LOT of deeply structured content files and folders (e.g. html, css, images, js, ...), this makes the build task unusable for such projects.

__Reason:__
The Copy task does not keep directory structure if used like this.

```
<Copy SourceFiles="@(LocalContentFiles)" DestinationFolder="$(OutputPath)" />
```

__Suggested Fix:__

The documentation of the Copy task contains an example at the end on how to use it to keep directory structure intact. Adjust the target file accordingly:

```
The following example demonstrates how to do a recursive copy.
This project copies all of the files recursively from c:\MySourceTree
into c:\MyDestinationTree, while maintaining the directory structure.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<MySourceFiles Include="c:\MySourceTree\**\*.*"/>
</ItemGroup>

<Target Name="CopyFiles">
<Copy
SourceFiles="@(MySourceFiles)"
DestinationFiles="@(MySourceFiles->'c:\MyDestinationTree\%(RecursiveDir)%(Filename)%(Extension)')"
/>
</Target>
</Project>
```
https://msdn.microsoft.com/en-us/library/3e54c37h.aspx


Comments: Correction for the suggested fix. This is what worked for me in the end: ``` <Copy SourceFiles="@(LocalContentFiles)" DestinationFiles="@(LocalContentFiles->'$(OutputPath)%(Identity)')" /> ```
Viewing all 48 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>