>
> You are missing a binding redirect from that version to whatever the newer
>> version is.
>>
>
> Normally I would redirect Extensions 4.2.0.0 to 4.2.0.1, but my assemblies
> are loose in a folder being called by Python.NET.
>
D'oh! There is a stupidly simple workaround for this. I manually
>
> You are missing a binding redirect from that version to whatever the newer
> version is.
>
Normally I would redirect Extensions 4.2.0.0 to 4.2.0.1, but my assemblies
are loose in a folder being called by Python.NET. One hint is that I need
to create a python.exe.config with the redirect next
I've just some some detective work to find out why Python calling my .NET
assemblies is crashing becaues it can't find
System.Threading.Tasks.Extensions 4.2.0.
My Framework 4.7.x library has caused the following stack of dependencies
to load.
(my library)
Azure.Storage.Blobs 12.10.0.0
Actually, I did get fuslogvw running quickly once I remembered to run the
exe as admin. No HKLM editing like I remembered.
Calling assembly : Azure.Storage.Blobs, Version=12.10.0.0, Culture=neutral,
PublicKeyToken=92742159e12e44c8.
:
LOG: Assembly Name is: System.Threading.Tasks.Extensions,
caught.
From: ozdotnet-boun...@ozdotnet.com On Behalf
Of Stephen Price
Sent: Wednesday, October 27, 2021 4:08 PM
To: ozDotNet
Subject: Re: DLL Hell
Interesting times indeed.
I think the point Greg made about so much code being from external sources,
often with uncontrolled/tested releases (which
It's not just the external libraries that cause so much DLL hell. I've
recently updated dozens of projects to use the latest Azure storage
packages and Cosmos DB packages and everything went haywire. The latter has
an internal hard dependency on Newtonsoft and it produced compile warnings
and
it...
That all said, I still prefer coding to cleaning gutters or digging holes!!
cheers
Stephen
From: ozdotnet-boun...@ozdotnet.com on behalf
of Craig vN
Sent: Wednesday, 27 October 2021 12:36 PM
To: ozDotNet
Subject: Re: DLL Hell
I have a large .NET 4.x
I have a large .NET 4.x project that needs upgrading to a new version. I
have decided that .NET 6 is the one, but I dread the thought of doing it,
hundreds of thousands of lines of code, outdated libraries.
On Wed, Oct 27, 2021 at 12:48 PM Greg Keogh wrote:
> It's not Friday but ... the last
>
> Every day when I open an older SQL code project, I'm thankful that it's
> likely to just work, unchanged.
>
Your reply is comforting (and as interesting as usual).
I think I'll go out and clean some gutters now and try to recover ;-)
*GK*
>
Hi Greg,
Every day when I open an older SQL code project, I'm thankful that it's likely
to just work, unchanged.
By comparison, every single time that I open a VS app project that I haven't
touched for a few months, I shudder about what I'm likely to have to spend time
fixing.
It's largely
10 matches
Mail list logo