Develop Reference

Consume all source code (non-compiled) from one project into another (PDFSharp)

As the title says, I want to consume all of PDFSharp's source code into my own project. But let me explain why I came to this scenario, so if there is something else I can do, maybe there are other options.
Goal: Compile my project into a single .exe file to use. No installers.
Problem: It uses PDFSharp.dll which is causing me issues.
What I am trying to do, is use ILMerge to create the .exe. I've used this successfully in the past for other projects.
The issue I think is that ILMerge is requiring references to other assemblies that PDFSharp uses. The first being Microsoft.ApplicationInsights. So to by-pass this, I installed Microsoft.ApplicationInsights into my project via Nuget. Then removed the actual reference from the project, but referenced the library in my ILMerge command as below:
/lib:"C:\<path to assembly>\Microsoft.ApplicationInsights.2.16.0\lib\net46"
This actually worked. Except, now it asked for another library and I get this error:
Unresolved assembly reference not allowed: GdPicture.NET.11.
This looks like a paid library, perhaps downloading the trial may get me past this. I didn't try yet. I switched gears as I felt I may be trying to reference an endless amount of assemblies.
I then tried to get the PDFSharp source code and I found that version 1.32 here:
https://sourceforge.net/projects/pdfsharp/files/pdfsharp/PDFsharp%201.32/
I added a reference to this project within my solution file, so now I have a solution with 2 projects. Great.
I then I tried to link source files into my project. How to do that is here:
https://jeremybytes.blogspot.com/2019/07/linking-files-in-visual-studio.html#:~:text=To%20link%20files%2C%20use%20the,CLICK%20THE%20%22Add%22%20BUTTON.
This seems to work, but every file I add requires another file, which references another file etc. It seemed endless. So that led me to the idea of just consuming the entire source code into my project and I haven't seen a good way to do that yet. I can't add a reference to the project as it just references the compiled dll which again, iLMerge can't combine.
I've also tried updating the tag within the .csproj file of PDFSharp to "module" to create a .netmodule file. This creates the file in the obj directory but throws an error:
\PDFsharp\code\PdfSharp\obj\Release\PdfSharp.netmodule' is not an assembly
Any help is appreciated. thanks.
UPDATE: I reversed everything and added the PdfSharp reference - back to where I was and changed my project to module and built which created a .netmodule file. Then used the assembly linker to create a .exe from that file. That worked using this command from VS Dev prompt.
al MyModule.netmodule /target:exe /out:MyProgram.exe /main:MyNamespace.MyClass.Main
This created the .exe, but when run without any other supporting files produces a file not found error:
System.IO.FileNotFoundException: Could not load file or assembly 'MyModule.netmodule' or one of its dependencies. The system cannot find the file specified.
Which is interesting since the module should be inside the exe right?

I have this working now, so I just wanted to place my results here since it is already posted.
My initial problem was that I mistakenly thought the PDFSharp.dll was causing the issue, but it was actually another group of 3rd Party dlls I was referencing.
I tried for hours to get iLMerge to work with the only success being it would kick out a single .exe file but it would have runtime errors.
Errors that I encountered:
Error: Unresolved assembly reference not allowed: Custom.Assembly.
Solution: Reference the assembly if possible. If you have many, you can reference a folder with the /lib:"C:\folderpath" switch.
Error: Unresolved assembly reference not allowed: ADotNetFramework.dll.
Solution: You can reference the desired .Net Framework path where iLMerge will search for missing references. Example: /targetplatform:"v4,C:<Path To Framework>.NETFramework\v4.8"
Error: The assembly 'xyz.dll' was not merged in correctly. It is still listed as an external reference in the target assembly.
Solution: You can get past this error with the /closed switch. However, I don't think I should even have gotten this error because 'xyz.dll' was a referenced dll to be combined.
Also - use the /log switch, it is extremely helpful in seeing exactly what iLMerge is doing and figuring out your issue. Example: /log:mylog.txt
This allowed me to see that iLMerge was finding duplicate namespaces, in the 3rd Party assemblies and automatically renaming them. Here is an example from my log:
Merging assembly 'My.Assembly.Name' into target assembly.
Duplicate type name: modifying name of the type '<>f__AnonymousType02' (from assembly 'My.Assembly.Name') to 'My.Assembly.Name.<>f__AnonymousType02'
Duplicate type name: modifying name of the type '<>f__AnonymousType12' (from assembly 'My.Assembly.Name') to 'My.Assembly.Name.<>f__AnonymousType12'
Duplicate type name: modifying name of the type '' (from assembly 'My.Assembly.Name') to 'My.Assembly.Name.
Finally - the solution that I found was not to use iLMerge. I found this Answer: https://stackoverflow.com/a/40786196/2596309
which used Costura.Fody
I installed the nuget package with:
Install-Package Costura.Fody -Version 4.1.0
Cleaned and built my solution and it created a single .exe file that I tested and it worked. Literally, I put 3 days of work into this and the solution took 3 minutes...

Is "Copy Local" transitive for project references?

Wrt. the proposed dupe: Since this here queston suggests the opposite of the linked question, I'd rather like to think it is not a dupe.
First, I did read What is the best practice for “Copy Local” and with project references? (also this) and I'll have to try this out anyway, but getting general feedback on this seems necessary as the docs on this stuff are horrible and I'm only on VS2010 and maybe they changed something in newer versions that'll be nice to know.
Second, I'm only interested in project references for this question as I've read that assemblies from the GAC are handled differently and the GAC is irrelevant for my problem.
Third, after reading the suggested dupe, but more so the nice answer here by #Albireo, it would also appear that it is important to differentiate file dependencies, where the dependency references a dll assembly file and project dependencies (i.e. what I'm asking about), where the dependency references a project and implicitly the output file of that project.
Anyway, here's the situation, somewhat peculiar I think, but still:
2 C# executable projects
n C# dll assembly projects
The 2 executables have different output directories as they will be deployed separately and that way they're also separate on the developer machine
The 2 executables have dependencies on some of the DLL assemblies (which may depend on each other)
There are three output directories:
/x1 for executable 1 project
/x2 for executable 2 project
/lib for all the dll assemblies
The DLL assemblies all have Copy Localset to false for their project references, as they all build to the same output directory.
The 2 executable projects have set Copy Local to true for all the DLL assembly project references they reference directly, so that the DLLs will be copied into /x1 /x2 respectively.
The question now is wrt. to DLLs that are not directly referenced by an executable project, but only transitively through a referenced assembly: Will assemblies, that are only referenced transitively through another assembly, be copied into the output folder of the executable, when "Copy Local" is set to true on the first assembly?
Example:
x1.csproj (e.g.Output = x1/one.exe)
Reference: dlA.csproj ( e.g. Output = lib/a.dll) with Copy Local = *true*
(no direct reference on b.dll)
dlA.csproj ( e.g. Output = lib/a.dll)
Reference: dlB.csproj ( e.g. Output = lib/b.dll) with Copy Local = **false**
(no direct reference on c.dll)
dlC.csproj ( e.g. Output = lib/c.dll)
(no further relevant references)
Thus, we have a logical dependency of one.exe -> a.dll -> b.dll -> c.dll, where only a.dll with obviously be copied to the output directory of one.exe. Will the other two dlls also be copied to the output directory? Is this documented somewhere?
And, yes, I tried it. And, yes, it seems to work, but I haven't poked it hard enough yet and anyway there maybe something more to it that I may have missed. (And also there's the question wrt. any official docs.)

it would also appear that it is important to differentiate file dependencies, where the dependency references a dll assembly file and project dependencies (i.e. what I'm asking about), where the dependency references a project and implicitly the output file of that project.
Not really, no.
MSBuild doesn't really care if the reference points to another project in the solution or to a DLL.
If ProjectA depends on ProjectB to build ProjectA ProjectB must be already built (and up-to-date), MSBuild will then pull its DLL (not its C# code) and link it to ProjectA.
Adding a project reference instead of a DLL is "syntactic sugar" for your convenience: this way MSBuild knows it must pick the output of the referenced project, whatever the output is.
Otherwise, you'll have to manually pre-build the dependency, find its DLL and link it to the project, repeating the process whenever you switch build configuration, move or rename things. Not really practical.
Will the other two dlls also be copied to the output directory?
If any kind of element from a dependency is used directly from the project where the assembly is referenced, that reference will be copied.
An example could be this solution layout:
MySolution
MySolution.ConsoleApplication
MySolution.FirstDependency
MySolution.SecondDependency
MySolution.ThirdDependency
MySolution.FourthDependency
With this dependency chain:
MySolution.ConsoleApplication
MySolution.FirstDependency
MySolution.SecondDependency
MySolution.ThirdDependency
MySolution.FourthDependency
If you build this solution you'll notice that in MySolution.ConsoleApplication output directory there will be the DLLs for MySolution.FirstDependency, MySolution.SecondDependency and MySolution.ThirdDependency but no DLL for MySolution.FourthDependency.
Why is it so? When MSBuild builds MySolution.SecondDependency it notices that there's a dependency declared to MySolution.FourthDependency, but since it can't find any usage of any kind of element from MySolution.FourthDependency in MySolution.SecondDependency code it decides to perform some "optimization" and omits MySolution.FourthDependency assembly from the output.
This same issue bit me in the past when I added through NuGet AutoMapper to a "deep dependency": adding AutoMapper adds two assembly references, AutoMapper and AutoMapper.Net4, where the second assembly is loaded by the first through reflection when it needs to perform certain kind of action on the new collection objects introduced by the .NET Framework 4. Since the second assembly is loaded through reflection MSBuild thinks it's unused and doesn't bother to copy it around.
So, yes, they will be copied as long as you're using them directly and not through reflection.
Is this documented somewhere?
This behavior seems to be a "feature" of MSBuild, I managed to find a blog post by some folks from Microsoft back when I experienced this issue, but I can't find it again at the moment.

It is very straight forward, doesn't have anything to do with Copy Local. MSBuild looks in the metadata of an assembly to see what the dependencies are for an assembly. So can you, run ildasm.exe on the assembly and double-click the Manifest. Be sure to try this to get insight. You'll see the .assembly directives. Inserted by the compiler when it built the assembly, only the referenced assemblies you actually used in your code will be listed.
If MSBuild can find such an assembly in the same directory then it will automatically copy it. If not then it will silently skip the copy.
From this, you can deduce the failure modes. It cannot copy unmanaged DLLs, they do not appear in the metadata. It cannot copy assemblies that you have an indirect dependency on through Assembly.Load/From(), they don't appear in the metadata either. It cannot copy assemblies that haven't been built yet, a build order problem. And it cannot copy assemblies whose Copy Local property you set to False. Which is normally only a valid choice if the assembly is present in the GAC, no copy required.
For such cases you need to help, XCOPY in a post-build event gets the job done.

CodeDom reference added properly, dll file is not

This has caused me a day's worth of work at this point. In visual studio I can add a reference to a custom-made .dll file. Once the reference has been added, I can call the .dll file:
someClass_inDll sc = new someClass_inDll();
sc.someVoid_in_dll();
Simple, right? No assembly use, invoking etc. needs to be done. I would like to be able to do this exact same thing using CodeDom! So, assume I have a custom .dll file (already made and on my hard drive), I have been adding the full path to said dll file to the list of codedom references. However, the actual .dll file is not being compiled with my project (as it is with visual Studio).
Can someone please tell me why this is? It's making no sense to me what so ever.
I do NOT want to add the .dll file as an embedded resource because the only way I could call functions in the dll file would be to invoke it which is something I'd rather not do for personal reasons.
I really appreciate the help everyone!
Thanks,
Evan

I am not sure I understand what you are asking, but here goes...
Visual Studio is copying all of your references into the output directory that are set to "Copy Local" in your .proj file AFTER compilation. The compiler itself is not concerned with the deployment of your dependencies, this is what msbuild is for.
So, when you add a reference to the CompilerParameters of your provider, it will use the reference to build the executable, but you will have to copy it yourself.

why would a .cs file not see updates to an included dll file

I have a dll containing classes to access data in SQL (a sort of ORM system) included in my .cs page with a using statement. For some reason the dll (with definition for a new field) isn't seen by the cs code, though I've uploaded the new dll in bin. It won't see my new field in the dll's helper classes (now compiled into the dll).
Is there a way to troubleshoot the dll, or the cs to tell why this won't see the class I updated and rebuilt? The class works fine locally and on another server, but on my prod server, it bombs.
This is using Sitefinity 3.7 with a Subsonic/Substage module if that sheds some light on it.

If you are using Visual Studio, verify 2 things, first:
try deleting csproj.user and .suo files (visual studio will recreate them)
The second thing is the version of the framework your project is running, and the version of the framework the dll was compiled in.
If your project is using .NET 4.0 but the DLL was built using 2.0 or similar you may not be able to use it, you can add it, but it wont be loaded.

This sounds so familiar... have you check to see if there is another dll on the path that gets resolved? Dynamic-Link Library Search Order

Make sure that your dll was not registered on the production service in the GAC.
How to extract an assembly from the GAC?

Perhaps you have a local copy of the DLL in your project and the DLL that gets updated is elsewhere.

I tend to think the dll you build is 32 bit (X86) dll. where as you are trying to consume it from project that targets "Any CPU".
Is your production server a 64 bit ?
If answer is yes, goto project properties => Build tab (of your cs code's project which is not understanding the dll) and set the Platform target as X86.

If the updated DLL has a different version number, you may need to update the Project Reference to it by deleting and re-adding a reference to the DLL in the bin folder.
If the project generating the DLL is present in the same solution, you may have an issue in creating a file reference (may not be updated) instead of a project reference (will be updated).

fuslog.exe is a great tool when troubleshooting assembly (dll) binding issues.
http://msdn.microsoft.com/en-us/library/e74a18c4.aspx

Another .net developer helped me figure this out. I had a rogue ToString() in there where there should have been a cast to string, allowing nulls. My dll was okay after all. Thanks everyone for your suggestions, I learned a lot.

"An assembly with the same simple name has already been imported" error without duplicate reference

I'm getting the following error:
error CS1704: An assembly with the same simple name
'Interop.xxx.dll, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null has already been imported. Try removing one of the
references or sign them to enable side-by-side.
Everything I've seen says that I am referencing two assemblies with the same name and I need to remove one of them. However, I've checked and I'm only referencing it once.
This also only happens when I'm using msbuild to build from the command line on my dev box. If I build through Visual Studio or do a clean build on our CI server I don't see this error.
I've tried completely removing all of my source and building from scratch to more closely resemble the build machine but no luck.

So it looks like I can't read today!
The project had a reference to the Interop and a COM reference that generated the "same" interop. So there were two and I just didn't search very well. I still don't understand why it worked in other places but this did fix it.

In the Error List window, the project that was triggering this error was listed in the Project column. I got around the error by doing the following:
I unloaded the listed project (right-click => Unload Project)
Opened the XML for edit (right-click the unloaded project => Edit {ProjectName.csproj}).
Searched for the offending .dll, and noticed it was listed multiple times in the XML
Removed the entire Reference tag related to the offending dll, and did so for every copy of the reference except the first one listed
The reason it was listed multiple times was because several referenced libraries used that dll. This shouldn't be a problem, in and of itself, so I'm not sure what caused this error to suddenly pop up for me. I'll update this answer if I figure that out.

In my case the duplicate entry was caused by a NuGet package reference and a direct file reference to the same assembly in the packages folder. I am not sure how the project got into this state, but unloading the project and searching the XML file for the offending assembly name resolved the issue for me.
Note that in my case this started happening after updating a NuGet package to a newer version with no other changes to the project, so this maybe caused by a bug in NuGet.

If this is a web project, are there any strong-named references to the other version there? Those won't show up as a project dependency, but will cause a run-time error like you describe. Hope that helps

I had this problem but in my case, I had an old copy placed in the current folder for the EXE loading my component, that was loaded together with the current one, that was loaded by hand from my projects folder. Deleting that old copy solved my problem.
I used Debug > Windows > Modules window to see which modules were loaded at that time and that solved my problem.

For others facing the same as me: if building via command line using property AssemblyName, it will overwrite all assemblies generated by all solution projects - in other words, you will end up with (N -1) assemblies named the same where N is the no. of projects - the startup one (which generally will generate an exe).
This happens because all build command line properties are global and overwrite any project-specific setting. See this and this.
From the msdn link mentioned above:
Global properties are properties that are set by using the
/property switch on the command line, or properties that are set by
the integrated development environment (IDE) before a project is
built. These global properties are applied to all projects that are
built by using this Engine.
In my specific case, where Jenkins is the CI tool, I ended up adding a windows batch command at the end to rename the .exe only to what I originally intended when passing the AssemblyName parameter.

For those developing UWP projects that have project references that include specifically the Microsoft.Windows.SDK.Contracts nuget package (or other dependencies that reference it), this is a common error when the version of the SDK contracts is targeting a different version of the runtime to how your project is configured.
For instance, when targeting Windows 10, version 1903:
Any dependencies or reference projects should target or at least support the same runtime version.
it is common thought process to update all NuGet packages when a new stable version is available, but this is not always a helpful practise on its own. Just because a new stable version of a package is available does not mean that you should or that you can easily use that version.
Even though this package for SDK contracts has a stable update, it is not compatible with my main project configuration, Nuget does not know this so it allows the update.
This package is specifically designed to provide windows dlls for project types that DO NOT have windows platform targeting support, it copies the same dlls that are included by the UWP targeting config. By installing later versions of the package the references from the satellite project will be included in the output along with those provided due to platform targeting, ultimately causing OPs error.
There are similar SDK and targeting packs for Windows IoT Device Runtimes, this information should help you identify and resolve those issues if you get stuck on this issue as my team often does :)

In my case, the issue was on wrong characters in the ProjectReference section of my csproj file.
Background
I have a project that references another library I maintain, which I publish as a NuGet package.
Whenever I make changes to my library, I usually reference the local dll in my project to test and make sure everything looks good before I publish the library as a NuGet package.
When testing, I just comment out the PackageReference line and uncomment the ProjectReference one so it references my local dll, like so:
<ProjectReference Include="..\..\my-class-library\MyClassLibrary.csproj" />
<!--<PackageReference="MyClassLibrary" Version="2.0.1"/>-->
Root cause
I had the slashes inverted, so I was using / rather than \ in the path, like so:
<ProjectReference Include="../../my-class-library/MyClassLibrary.csproj" />
Once corrected, the issue went away.

Try this instead: remove Interop.xx.dll from the reference section in Solution Explorer and Rebuild the project

In our case this error was shown when we had a duplicate reference inside the .csproj file (although I have no idea how this happened).
The difference to an already posted answer is that, in our case, one was a project reference and another one was direct binary reference to a dll.
Once we removed one of those, project correctly compiled.