Develop Reference

Resolve conflict between System.Drawing and System.Drawing.Common

I am trying to add SpreadSheetLight to a new Dnn v9.10.2 project running on Windows Server 2019, but I get a runtime error saying
CS0433: The type 'Image' exists in both 'System.Drawing.Common,
Version=4.0.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' and
'System.Drawing, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'
when I copy the dlls into the bin folder. I have a file that was using System.Drawing, but it was using the full namespace in it's references. I tried updating those to System.Drawing.Common, but it instead throws the error
CS0234: The type or namespace name 'Common' does not exist in the
namespace 'System.Drawing' (are you missing an assembly reference?)
Commenting out the lines of code using System.Drawing resolved the runtime error, but ultimately when trying a simple test of just opening and closing a blank workbook it throws the exception
System.PlatformNotSupportedException: System.Drawing is not supported
on this platform.
I haven't been able to find much on how to fix this so any help would be appreciated.

Upon first glance it seems that this library is a .NET 3.5 library and DNN Platform 9.10.2 is .NET Framework 4.7.2 you are most likely hitting a compatibility issue with changes in .NET 4.7.
It looks like the source for SpereadSheetLight is available, you could try to recompile it for .NET 4.7.2 and see if you can clear the issue.

MSB3258: mscorlib 4.0.0.0 and 2.0.0.0

So I'm trying to compile a project on VS 2017, and I'm getting this:
warning MSB3258: The primary reference "someLib.dll" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.
After that, I have errors relating to this dll (for example, a type or namespace not being in the namespace), but when I double click the error it disappears, along with the red squiggly line in the code, hinting at the fact that it's not the actual problem.
Nothing I tried is working: all of the projects are on 3.5, I removed and re-added all of my references, and it doesn't happen in any other computer except my own. I also tried removing mscorlib from the GAC (however dumb that may be), but of course it won't let me.
I saw something that may be relevant:
https://developercommunity.visualstudio.com/content/problem/230636/assemblydependency-now-misidentifying-indirect-dep.html
Other than removing and reinstalling VS, not sure what to do.
If anyone has any idea, I'd be glad to try it.

It was a weird reference to a version of Interop.Shell32.dll called just "Shell32.dll". Don't know where it came from.
If anyone else has this issue: remove each dependency one at a time and compile. Even the Microsoft ones.

Answer from comments:
Check the libraries someLib.dll references. Maybe they contain a reference to mscorlib.dll 4.0.0.0.
Hint: add official Microsoft libraries via Via Add Reference > "Assemblies tab" (on the left, don't know if tab is correctly named). Don't add them by browsing for them.

Do I need to modify my existing csproj or add a project.json file to a command project that references a new .net standard library?

I have recently made the decision to try and re-standardise my older style PCL's from the (apparently archaic) old approach of portable-net451+win81+wpa81 to now netstandard1.x. I took this decision as Xamarin Forms on my Mac was no longer recognising one of my libraries as a NuGet package.
Anyway, having started this conversion I have entered a world of unknown pain in the sense that it isn't a very automatic process. I'm now at the stage where I think I've converted my PCL's to net standard libraries but now I'm trying to reference these standards within a 'normal' windows console app I get odd errors.
Primarily my errors are thus:
Error CS0012: The type System.Linq.IQueryable 1<TItem> is defined in an assembly that is not referenced. Consider adding a reference to assembly System.Linq.Expressions, Version=4.0.10.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (CS0012)
Error CS0012: The type System.Collections.IEnumerable is defined in an assembly that is not referenced. Consider adding a reference to assembly System.Runtime, Version=4.0.20.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (CS0012) (Redbridge.Console)
Now given that my project is referencing one of my net standard libraries and this error originates from me using a class that requires packages System.Linq.Queryable and System.Linq to be added specifically to my net standard library I can't help but wonder how I'm meant to make this work in my console app library. I note that the versions are .20 rather than the standard .0 so what do I do to make this work?
I've tried the obvious (referencing the above packages in my console app as suggested by the compiler) but to no effect. Does anyone have any advice? Do I need to add a project.json file for example to my console app so that I can indicate that .NET standard should be used or something?
I've read quite a bit on the .NET standard and like most find it confusing as to what I'm expected to do.

Runtime error: Could not load file or assembly - Modules with different CPU types were found

I'm getting the following runtime error in my WCF service.
Could not load file or assembly 'MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
After some looking around, I found a suggestion to use Assembly Binding Log Viewer, or Process Monitor. Neither or which yielded any information (that is, the log viewer showed nothing at all, and the process viewer didn't see the assembly load being attempted.
I finally came across a suggestion to use this utility (dependency walker) to find out what the assembly was actually looking for. On opening, I got an error immediately; and the log stated the following:
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
According to the module list, it couldn't find these:
API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
IESHIMS.DLL
Some of these look like they relate to the RT framework; however, this application was developed in .NET 3.5 (actually, that's not strictly true - it was developed in 4.5 and downgraded to 3.5).
Looking at some of these files seems to imply they are quite core Windows files, and oddly, I have used this dll elsewhere in the solution (admittedly on the client) without issue.
I'm using VS2013 although I've tried VS2012 and get the same issue.
I did come across this question which at first glance seems to be the same, although it relates to C++.
Can anyone give me some guidance as to what the issue might be, or what to try next?
Here is my fusion log:
=== Pre-bind state information ===
LOG: DisplayName = MyAssembly.MyLib.XmlSerializers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, processorArchitecture=MSIL (Fully-specified)
LOG: Appbase = file:///c:/myprog/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = myprog.exe
Calling assembly : System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: c:\myprog\bin\Debug\myprog.exe.config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
I managed to reduce the library in question down until it was just a single static function that returns a string, and still get the error.

The thing that always helped me with resolving this error was to take closer look at the part of the error message which says "or one of its dependencies".

Visual Studio with WCF has a quirk - if you build using a selected platform, it dumps the assembly in a platform-specific folder. If you build with "Any CPU" it puts it in the root of your WCF's "Bin" folder.
When it configures IIS to help you? It automatically assumes your assemblies will be in the root of that "Bin" folder.
The net event is that when you select "x86" instead of "Any CPU" you end up with the assemblies built in the wrong spot and suddenly your WCF does not run. So this is one of the few rare cases where the catch-all error about not being able to load your file or assembly is telling the literal truth - Visual Studio put your assembly in the wrong place and now it can't find it.
I have no idea why they did it like that. WCF has some... interesting design decisions.

If you have multiple projects, it is possible some of them are not building when you run the application in Visual Studio. Right click on your solution, then go to Properties, Configuration Properties and confirm all the projects are set to compile.

So the library that is part of your WCF service has one method and that is the problem method.
Can the method and it's reference be removed and does the runtime error go away?
It would be helpful if you could post the source to the project file and you should consider recreating the project file from scratch.
In that way if there are any stale references to 4.x they will be removed, please post more about your progress...

I've always found that could not find is always because it is not there.Sounds perhaps obvious but sometimes helpful to get the mind right => There is something which is not there.Next well if you remember the principle of decoupling the definition from the implementation it goes to imply that your library containing the interface and the service should move to an external dll to the service. now that you've externalized the acting code, if that builds in itself, you've only the implementation left. Which being a downgraded solution a pragmatic approach is that the project has become 'funny'. Make new project specific to your task an version and since it very likely only now contains reference to your library and a file with one line called something like thisismyservicename.svc as well as an address and a binding it should be pretty easy to copy the system.servicemodel part of your web.config. Now you have nothing left in your original project and can flush is safely.

Looks like I'm not the only person that's been here. I'll leave this up in case it helps anyone else:
http://social.msdn.microsoft.com/Forums/en-US/9f0c169f-c45e-4898-b2c4-f72c816d4b55/strange-xmlserializer-error?forum=asmxandxml
Just ignore the error... that how it's supposed to work!?
EDIT:
I've undeleted this answer for future reference. I finally solved the problem. It wasn't the issue above, it was an IIS problem specific to the solution I was working with. There was a post build to copy compiled WCF binaries to a common location, but that obviously didn't include the new dependency.
I'll award to the closest answer.

I have experienced the same issue with wcf, I have the project working and after adding a wcf service it stop loading the svc file and the same issues, nothing worked for me, and at the end I removed the service and restart the machine, the rebuild everything and at the end I added the service again.

This error generally given while project is developed in greater version of visual studio/Asp.Net and run/deployed machine has a lower version. Firstly check Visual Studio version of both machine.

"Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Validation" exception

I am currently getting the following exception while trying to use the Enterprise Library Validation Application Block:
An error occurred creating the configuration section handler for validation: Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Validation, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) (C:\Documents and Settings\My Documents\Visual Studio 2008\Projects\Testers\TestProject\web.config line 12)
I know what the exception is trying to tell me, but I can't figure out how to fix it. I have only ever installed one version of the Enterprise Library, and this is it (4.1.0.0), so I don't see how it could be finding the wrong version, so I imagine it is then a dependency problem. I have included the "Common", "Validation" and "ObjectBuilder2" DLLs from the Enterprise Library 4.1 as references in the project, so I'm not sure what else I'm missing. The documentation certainly seems to indicate this is all I need.
Is there any way to track down what the dependency problem is?
If it helps, I am trying to use the Enterprise Library Configuration Tool to create a Validation Application Block rule set for validation of data in an Entity Framework entity. I am using ASP.NET MVC in Visual Studio 2008.
Thanks for any assistance/direction you can provide,
Chris

Turn on Fusion logging and see what assembly is being bound at runtime.
Hanselman had a post recently that should be helpful in enabling logging and examining the output.
http://www.hanselman.com/blog/CommentView.aspx?guid=3654c8f3-c5c3-4dee-a01f-c9a8da3ef2fa
Another important distinction to make is that references that are added to the project are compile-time references and don't affect the way that code is bound at runtime other than to specify a strong name if a strongly named assembly was used. In order to find out what is happening at runtime you need to look at the binding logs. The log should show you all of the attempts that the runtime makes at locating the assembly. If the assembly is not in the bin directory along with your exectuable, it is most likely looking in the GAC and finding a version that it does not expect.
Note that the compiler DOES NOT use the GAC when referencing assemblies. So most probably you have a different version used as a reference in the project than you have installed in the GAC.
Also, it is very easy to find out what version you have installed in the GAC by looking in C:\Windows\assembly using Windows Explorer. The version that is specified in your error message will be the version that was referenced during compilation. If these versions don't match this could be your problem, assuming that Fusion is indeed looking in the GAC (which will be evident by looking in the Fusion log).