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...
I've looked at this question:PrecompileBeforePublish using Msbuild, but it doesn't fully address my issue. In trying to use PrecompileBeforePublish=true for our build of a web application, I am getting an error and build failure when MSBuild encounters a referenced DLL that is not a managed code assembly (it is a 3d party .dll we use for data access). If I set PrecompileBeforePublish=false, or just take the property out of the publish file, the build completes as expected.
My question is whether there are any attributes for this property that can be used to avoid this particular issue, or whether I am just stuck with the simple binary true/false value of the property. I suspect the latter.
To clarify per Sayed's question: I was attempting to precompile the application, so did in fact have PrecompileBeforePublish set to true in my publish profile that I am using to create the deployment package.
We are referencing some .dll's for data access that are compiled as unmanaged code. I suspect what is happening is that when we precompile, since our solution is managed, it (the build process) barfs when it encounters a referenced .dll that is unmanaged. The error we get is: "ASPNETCOMPILER: error ASPCONFIG: Could not load file or assembly 'xxx' or one of its dependencies. An attempt was made to load a program with an incorrect format.
I've built an application using Spring.Net. I've run into a scenario where it is necessary to rename the executable. I thought the easiest way would be to rename the .exe and its .config file, however this causes a TypeLoadException during ContextRegistry.GetContext().
Here's a look at the structure:
-Release
|-Library.dll
|-MyApp.exe
|-MyApp.exe.Config
|-SpringConfigFile.xml
And within the SpringConfigFile I have:
<object id="ObjFromLibrary" type="Library.SomeType, Library">
<!-- properties go here -->
</object>
<object id="ObjFromMyApp" type="MyApp.SomeOtherType, MyApp">
<!-- properties -->
</object>
(Of course, this is simplified and I have many objects whose type derives from the MyApp assembly)
The exception reads:
Error creating context 'spring.root': Could not load type from string value 'MyApp.SomeOtherType, MyApp'. ---> Spring.Core.CannotLoadObjectTypeException: Cannot resolve type [MyApp.SomeOtherType, MyApp] for object with name 'ObjFromMyApp' defined in file Release\SpringConfigFile.xml] line 5 ---> System.TypeLoadException: Could not load type from string value 'MyApp.SomeOtherType, MyApp'.
Which basically indicates Spring had no problem creating the object ObjectFromLibrary, but failed on ObjFromMyApp (in my "real-world" application, ObjFromMyApp is the first object dependent on MyApp and not another dll)
My question is, is there a way to easily rename this .exe and not have Spring fail to load? I know I could rebuild the project with a new name and refactor the SpringConfigFile.xml to use the new assembly, but I'd prefer to do it without a rebuild. If this requires refactoring the project once so that I can rename it later, that would be acceptable as well.
Another more philosophical question is, should I expect renaming an .exe file to cause a .NET program to stop working?
I know I could rebuild the project with a new name and refactor the
SpringConfigFile.xml to use the new assembly, but I'd prefer to do it
without a rebuild.
You don't need to rebuild the project. Only modify the contents of SpringConfigFile.xml so that it uses the new name of the assembly.
Another more philosophical question is, should I expect renaming an
.exe file to cause a .NET program to stop working?
This would entirely depend on how this program is designed and what it is doing. As you have already discovered in your case Spring.NET uses runtime binding to the actual type and if the assembly in which this type is declared is modified it will break the configuration.
So basically you will need to perform the update of the xml configuration file and the rename of the executable at the same time.
I am not sure whether Spring.NET supports fluent API to configure your container but some other DI frameworks such as Ninject certainly do and are more stable to such renames because the container setup is made with code instead of some weakly typed magic strings XMLs.
I know the error message is common and there are plenty of questions on SO about this error, but no solutions have helped me so far, so I decided to ask the question. Difference to most of similar questions is me using App_Code directory.
Error message:
CS0012: The type 'Project.Rights.OperationsProvider' is defined in an
assembly that is not referenced. You must add a reference to assembly
'Project.Rights, version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
Source File:
c:\inetpub\wwwroot\Test\Website\App_Code\Company\Project\BusinessLogic\Manager.cs
Following suggestions here and here, I have deleted all instances of Project.Rights.dll inside C:\Windows\Microsoft.NET/*.*
According to this, I checked if .cs files in question have build action set to "Compile". They do.
I have also double checked that the .cs file containing the "Project.Rights.OperationsProvider" type is deployed to App_Code directory.
For some reason, application is not looking for the type in the App_Code directory. Since I've deleted all instances of Project.Rights.dll (that I know of), I don't know which assembly the error message is mentioning.
When you get this error it isn't always obvious what is going on, but as the error says - you are missing a reference. Take the following line of code as an example:
MyObjectType a = new MyObjectType("parameter");
It looks simple enough and you probably have referenced "MyObjectType" correctly. But lets say one of the overloads for the "MyObjectType" constructor takes a type that you don't have referenced. For example there is an overload defined as:
public MyObjectType(TypeFromOtherAssembly parameter) {
// ... normal constructor code ...
}
That is at least one case where you will get this error. So, look for this type of pattern where you have referenced the type but not all the types of the properties or method parameters that are possible for functions being called on that type.
Hopefully this at least gets you going in the right direction!
Check target framework in the projects.
In my case "You must add a reference to assembly" actually meant, that caller and reference projects didn't have the same target framework. The caller project had .Net 4.5 , but referenced library had target 4.6.1.
I am sure, that MS compiler can be smarter and log more meaningful error message. I've added a suggestion to https://github.com/dotnet/roslyn/issues/14756
In my case this was because doing a NuGet package update had only updated references to a dll dependency in some but not all projects in my solution - resulting in conflicting versions. Using a grep-style tool to search text within *.csproj files in my solution it was then easy to see the projects that still needed to be updated.
When you get this error, it means that code you are using makes a reference to a type that is in an assembly, but the assembly is not part of your project so it can't use it.
Deleting Project.Rights.dll is the opposite of what you want. You need to make sure your project can reference the assembly. So it must either be placed in the Global Assembly Cache or your web application's ~/Bin directory.
Edit-If you don't want to use the assembly, then deleting it is not the proper solution either. Instead, you must remove all references to it in your code. Since the assembly isn't directly needed by code you've written, but instead by something else you're referencing, you'll have to replace that referenced assembly with something that doesn't have Project.Rights.dll as a dependency.
In my case, I was referencing a library that was being built to the wrong Platform/Configuration (I had just created the referenced library).
Furthermore, I was unable to fix the problem in Visual Studio Configuration Manager -- unable to switch and create new Platforms and Configurations for this library. I fixed it by correcting the entries in the ProjectConfigurationPlatforms section of the .sln file for that project. All its permutations were set to Debug|Any CPU (I'm not sure how I did that). I overwrote the entries for the broken project with the ones for a working project and changed the GUID for each entry.
Entries for functioning project
{9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.ActiveCfg = Release|x64
{9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.Build.0 = Release|x64
Entries for corrupted project
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Debug|Any CPU
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Debug|Any CPU
Corrupted entries now fixed
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Release|x64
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Release|x64
I hope this helps someone.
It just happened to me that different projects were referencing different copies of the same dll.
I made sure all referenced the same file on disk, and the error disappeared as I expected.
Unloading and reloading the class library in Visual Studio solved this for me.
For me, this was caused by the project both directly and indirectly (through another dependency) referencing two different builds of Bouncy Castle that had different assembly names. One of the Bouncy Castle builds was the NuGet package, the other one was a debug build of the source downloaded from GitHub. Both were nominally version 1.8.1, but the project settings of the GitHub code set the assembly name to BouncyCastle whereas the NuGet package had the assembly name BouncyCastle.Crypto. Changing the project settings, thus aligning the assembly names, fixed the problem.
It didn't work for me when I've tried to add the reference from the .NET Assemblies tab.
It worked, though, when I've added the reference with BROWSE to C:\Windows\Microsoft.NET\Framework\v4.0.30319
I had this issue on a newly created solution that used existing projects. For some reason, one project could not "see" one other project, even though it had the same reference as every other project, and the referenced project was also building. I suspect that it was failing to detect something having to do with multiple target frameworks, because it was building in one framework but not the other.
Cleaning and rebuilding didn't work, and restarting VS didn't work.
What ended up working was opening a "Developer Command Prompt for VS 2019" and then issuing a msbuild MySolution.sln command. This completed successfully, and afterwards VS started building successfully also.
one of main reason can be the property of DLL
you must before do any thing to check the specific version property if it true make it false
Reason:
maybe the source code joined with other (old)version when you build it , but this Library upgraded with new update the version now different in the Assembly Cash and your application forbidden to get new DLL ,and after disable specific version property your applacaten will be free to get the new version of DLL references
Maybe a library (DLL file) you are using requires another library. In my case, I referenced a library that contained a database entity model - but I forgot to reference the entity framework library.
This can also mean you use a library, which exposes (public) types that are defined in a library. Even when you do not use these specifically in your library (the one that doesn't build).
What this probably prevents is you writing code that uses a class (which in its signature has the types from a library not referenced) that you cannot use.
For me the reason why the error appeared was that the WebForm where the error was reported has been moved from another folder, but the name of its codefile class remained unchanged and didn't correspond to the actual path.
Initial state:
Original file path: /Folder1/Subfolder1/MyWebForm.aspx.cs
Original codefile class name: Folder1_Subfolder1_MyWebForm
After the file was moved:
File path: /Folder1/MyWebForm.aspx.cs
Codefile class name (unchanged, with the error shown): Folder1_Subfolder1_MyWebForm
The solution:
Rename your codefile class Folder1_Subfolder1_MyWebForm
to one corresponding with the new path: Folder1_MyWebForm
All at once - problem solved, no errors reporting..
The type 'Domain.tblUser' is defined in an assembly that is not
referenced. You must add a reference to assembly 'Domain,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
**Solved:**
Add reference of my domain library layer to my web app libary layer
Note: Make sure your references are correct according to you DI container
In my case this was because I used
Implicit Operator
between BLL and DAL classes.when I want to use BLL Layer In Application Layer I got this error.
I changed
implicit operator
to
explicit operator
it be OK.
Thanks
In my case the version of the dll referenced was actually newer than the one that I had before.
I just needed to roll back to the previous release and that fixed it.
I have a similar problem, and I remove the RuntimeFrameworkVersion, and the problem was fixed.
Try to remove 1.1.1 or
My problem was that the Output Type for one of my projects was set to Console Application. To fix this, I right-clicked the project, chose Properties, clicked the Application tab, and change Output Type (from Console Application) to Class Library. After I re-compiled, this error went away.
Clean your solution and rebuild worked for me (in Visual Studio, these are options you get when you right click in your solution explorer), the error is gone in my project.
I'm building a Silverlight 4.0 application with .NET Framework 4.0, and I'm seeing this error:
Reference to type System.Action claims it is defined in 'c:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\mscorlib.dll', but it could not be found (CS1684) - c:\Program Files\MSBuild\Seesmic\SDP\Seesmic.Sdp.Utils.dll
In my project I have a reference to the same mscorlib.dll that it's claiming to be defined in. Any ideas?
That's an odd location for a DLL (within the MSBuild directory). Is it possible that it's trying to use a reference to a desktop assembly from within your Silverlight application? Admittedly with the assembly portability in v4 I'd half expect that not to be a problem, but it's worth looking into.
If you could give more details about how you're building and where Seesmic comes into the frame, that would help.
Seesmic.Sdp.Utils.dll is probably requiring a different version of the mscorlib.dll because it was compiled referencing that different version. In Seesmic.Sdp.Utils.dll there is a class using System.Action as base class, that only works if you reference the same version of mscorlib.dll containing the same System.Action, otherwise you won't be able to use that class.
Sometimes you create a class say 'YourClass.cs' in your project say 'YourProject.YourModule'. After some time, you comment out YourClass.cs content since you do not want it now. But you do not exclude that .cs file from your project. In such case, compiler will give you warning while building the project like 'claims it is defind'. This is because project file contains the entry for this .cs file. When someone tries to use reflection on that project dll then this error prevents the code from accessing that class since it is actually not present physically but only in project file.