Closed scott-boulette closed 6 years ago
In your app.config or web.config you can map a range of versions so that it resolves to the version you have:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="protobuf-net" publicKeyToken="257b51d87d2e4d67" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.3.12.0" newVersion="2.3.12.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Rush,
Thanks for getting back to me so quickly. I did that but likely in the wrong place. I have protobuf-net dll, StackExchange.Redis.Extensions.Protobuf.dll, within my GtG_Common.dll which is in turn a dependency of my NTBridge.dll which is what is being called from within NinjaTrader. I have the xml below in all the dll's I wrote, should it be somewhere else as well?
Best regards, Scott
It should be in the config of whatever application is being executed and loading the protobuf-net.dll. It sounds like it should be the NinjaTrader config.
Thanks again. I am not sure I have access to that but at least it gives me something to try. If it matters, NinjaTrader is loading the correct version of protobuf-net.dll (I can see that in their logs) but for some reason when StackExchange.Redis.Extensions.Protobuf.dll is first called, it attempts to load the minimum version as defined by its dependencies in nuget even though the correct version of protobuf-net.dll was previously loaded by NinjaTrader. It is that load attempt that fails.
I have determined it is definitely an app.config issue. If I run it in my test app without the bindingRedirect, I get the same failure with the same message and once I put the bindingRedirect back in, all is good. The issue I have now is there is no app.config in the NinjaTrader application or at least not one I can get to. Is there anything I can do relative to your modules? If not, I will always be stuck at the minimum requirements i.e. protobuf-net 2.3.7.0 until that is moved up. The only other possibility I can think of is for me to make a pull request where the only change I make is the protobuf-net version loaded - I am not technically capable of making the load dynamic is some more technically elegant way.
Any thoughts?
How are you able to add StackExchange.Redis.Extensions but not modify the app.config? Do they have some kind of hosting platform where they let you add dll's or nuget packages but not edit the config?
I got it sorted out, it was an issue on my end that I solved by handling the references differently.
On Fri, Jul 20, 2018 at 4:39 PM Rush Frisby notifications@github.com wrote:
How are you able to add StackExchange.Redis.Extensions but not modify the app.config? Do they have some kind of hosting platform where they let you add dll's or nuget packages but not edit the config?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/imperugo/StackExchange.Redis.Extensions/issues/137#issuecomment-406720610, or mute the thread https://github.com/notifications/unsubscribe-auth/AbecT84mtDqBmtYPxDd7_V208pxtOYGJks5uIkAUgaJpZM4UpqAN .
I have an issue I believe is due to another package (not yours) but the stack trace always ends in your code. An application I use (NinjaTrader 8) allows one to compile code within their environment that accesses 3rd party dll's. I have a dll that accesses Redis using protobuf-net as the serializer. When the strategy (effectively a compiled c# script that accesses my dll which uses your dll) first loads, it loads all the required dll's one of which is mine that uses redis/protobuf and indeed loads the correct version of protobuf-net 2.3.12.0 (which is the only version I have on my system and the one which all my code uses).
However the stack trace shows that on the first call to your code, what looks like some sort of lazy load occurs and that in turn attempts to load 2.3.7.0 of protobuf-net which is nowhere on my system. I have tried everything I can possibly think of (hours and hours spent on this) even to the point of allowing nuget to get protobuf-net 2.3.12.0 when adding your package by deleting the protobuf-net package and then choosing highest for dependency resolution when getting StackExchange.Redis.Extensions.Protobuf. I tried adding all the dll's involved into a stand alone exe not involved in any way with NinjaTrader 8 and all works fine. My guess is that is because the code all loads the required dll's in the proper order.
My ultimate question - is there any sort of configuration I can do to let StackExchange.Redis.Extensions.Protobuf know the proper dll has already been loaded or alternatively get it to load the proper one (2.3.12.0) instead of the old one (2.3.7.0)? I notice that 2.3.7.0 is the minimum version in your dependencies list. Below is the stack trace if it helps. As an aside, I am more of a trader than a developer and while I know c# decently well, anything to do with a deployment either goes perfectly or turns into a nightmare like the current situation. Any help or direction will be greatly appreciated. I did contact Marc Gravell (who I have had much correspondence with over the years due to being an early adopter of his package) but he said this was something only you could likely help with.
Thanks, Scott
12:35 AM ExternalMessageManager:ConnectAsync failed System exception Could not load file or assembly 'protobuf-net, Version=2.3.7.0, Culture=neutral, PublicKeyToken=257b51d87d2e4d67' or one of its dependencies. The system cannot find the file specified. at StackExchange.Redis.Extensions.Protobuf.ProtobufSerializer.Serialize(Object item) at StackExchange.Redis.Extensions.Core.StackExchangeRedisCacheClient.Add[T](String key, T value) at NTBridge.Redis.ExternalMessageManager.PersistMessage(ICacheClient cacheClient, String key, String msg) in C:\Users\Scott\Documents\Visual Studio 2017\Projects\NTBridge\NTBridge\Redis\ExternalMessageManager.cs:line 300 at NTBridge.Redis.ExternalMessageManager.RegisterConnection(ICacheClient cacheClient) in C:\Users\Scott\Documents\Visual Studio 2017\Projects\NTBridge\NTBridge\Redis\ExternalMessageManager.cs:line 258 at NTBridge.Redis.ExternalMessageManager.VerifyCredentials(MessageEndPoint messageEndPoint) in C:\Users\Scott\Documents\Visual Studio 2017\Projects\NTBridge\NTBridge\Redis\ExternalMessageManager.cs:line 247 at NTBridge.Redis.ExternalMessageManager.d__25.MoveNext() in C:\Users\Scott\Documents\Visual Studio 2017\Projects\NTBridge\NTBridge\Redis\ExternalMessageManager.cs:line 128