Image.Load() => {"Could not load file or assembly 'System.Runtime, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.":"System.Runtime, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"}
My project can be found on my github here.
I am just trying to run it as native 4.7.1 without CORE for Main UI.. I have my dependancy libs x-targeted for both Core2.0 and 4.7.1 but that shouldnt do anything. Im sure the problem is with ImageSharp pack v1.0.0-beta002 (latest)..
Because I didn't have any problems prior to installation the issue is I need to not have a binding redirect from the package from System.Runtime. It is now integrated as part of STD.
System.Runtime from NuGet package (latest) installation targets 4.6.2. It is incompatible and will not load if copied. In fact, if you Browse to include it as a referenced assembly, you get a yellow exclamation box. More than likely, conflicting or incompatible.
I am thinking the only thing I know how to do is revert to stable package 1.5 but thats 6 mo old and the constructs are different for things.
As workaround, I was able to include this library from Reference assemblies and then under Properties, change the alias to "newVer" or whatever you wish.
Then in your project in the source code, you need to add:
extern alias newVer;
Where you then pre-pend the namespace like so.
using (var zip = ZipFile.Open(backupFilePath, newVer::System.IO.Compression.ZipArchiveMode.Create)) { ... }
This will not work for System.Runtime since there is not one to be found in Reference assemblies anymore.
I will try to download the src and repack it today against v4.7.1 but I would also like to mention:
_System.IO.Compression_ should be added to the #567.
SixLabors.ImageSharp.1.0.0-beta3.nupkg

@Latency I'm not able to build your project, half of the solution is reported being missing.
Installing and using ImageSharp in an empty 4.7.1 project works perfectly for me! Have you tried cleaning/reinstalling your NuGet stuff?
I concur I have no problem installing ImageSharp in a new 4.7.1 project in either csproj based PackageReference or the older packages.config style of reference.
Like @antonfirsov I also can't get the project to run.. even after running the bootstrap.bat and even trying to build all the projected individually.
I'm adding a link here to a Windows classic desktop app targeting NET 4.7.1 running beta 2 built using VS 15.5.3
I'm able to resize a png (thus touching compression at runtime) without issue.
Here's another console app this time targeting both NetCore 2.0 and NetFramework 4.7.1
Yes, there are 4 projects split up in HearthSim to make this one work.
I have bundled everything together to replicate in this here.
I have confirmed that the problem IS the build and release from your package.
After spending a day to repack it.. It is now working with my latest release of ImageSharp (as submitted to the PR) as the dependencies and reference assemblies are resolved correctly now.
@Latency your bundled solution works perfectly for me! (Image.Load() is being called without problems.) Looks like the problem is related to your environment. Might be a .NET Framework / .NET Standard issue. I suggest to ask for help on Microsoft forums.
Please check out our latest comments on gitter and #434! We are not going to accept your PR-s.
I'm closing this as 'can't reproduce'. If you believe this is closed in error please provide a simpler solution/project that reproduces the error.
No, this should NOT be closed, there are tons of such problems with net 4.7.1 inconsistencies causing build or runtime errors of this sort. I've been unable to update multiple projects to full net framework 4.7.1 because of these issues for months and months, after many extremely painful failed attempts to do so. I can't believe this has not been fixed yet, and that there is no movement on this issue! The whole net team should stop their work and make sure to remove these dll hell inconsistencies between the full framework and the newer net core bits, because they aren't playing well together, and many of us are at a breaking point. An exaggeration (about them stopping all other work to fix this)? No, maybe an understatement. It is frankly an embarrassment that such glaring problems were allowed and for so long, all the while most the team goes on making these wonderful new improvements to Net Core (which on their own I love), that's awesome, but not awesome that that work now makes it so our big projects on full framework can't even update to another newer full net framework version! And that itself becomes critical for certain reasons, and yet we go on an on with no fix.
For instance, this problem is not just with System.Runtime, it is also with System.Net.Http, it seems as soon as you upgrade from a lower full framework (in my case from net 4.6.1) to 4.7.1, suddenly it's like the framework is expecting references to the nuget System.Net.Http, which would be fine, except that any dependencies, anywhere, that ever reference a full framework version of System.Net.Http, cause non-compilable errors at build time.
Nice unwelcome rant but what has this got to do with our library and immediate issue?
@copernicus365 then like I said in my reason for closure, instead of ranting unhelpfully, please provide a verifiable reproduction of the original issue and I would be happy to reopen the ticket. But note this will stay closed as 'Can reproduce' until the development team (who have made this library in our free time, and thus have no obligation to fix any issues raised at all) can reproduce the problem (and thus can try and fix it).
If on the other hand you are complaining about the way .Net Standard targeted libraries are installed into full framework projects then that's an issue with nuget/dotnet as a framework and not an issue with a single library, then I suggest you raise your concerns with Microsoft instead of an independent dev team who have no control over these things.
Sorry guys, I missed that this was not one of the netfx repos. It does come up as one of the top hits on google for net 4.7.1 problems, and the title is worded well for that, but again, missed it's on a specific library. Cheers
Most helpful comment
@copernicus365 then like I said in my reason for closure, instead of ranting unhelpfully, please provide a verifiable reproduction of the original issue and I would be happy to reopen the ticket. But note this will stay closed as 'Can reproduce' until the development team (who have made this library in our free time, and thus have no obligation to fix any issues raised at all) can reproduce the problem (and thus can try and fix it).
If on the other hand you are complaining about the way .Net Standard targeted libraries are installed into full framework projects then that's an issue with nuget/dotnet as a framework and not an issue with a single library, then I suggest you raise your concerns with Microsoft instead of an independent dev team who have no control over these things.