lunes, 12 de marzo de 2012 12:55
I've been developing against the Windows AppFabric Cache v1.1 (and previously 1.0) for a few months now... recently I also installed the Azure SDK on my development machine to do some prototyping with the Azure ServiceBus.
I sincerely don't remember referencing the Azure dlls (except Microsoft.ServiceBus.dll); and I could be wrong, but I've noticed that several of my assemblies referenced the Azure version of Microsoft.ApplicationServer.Caching.Client and Microsoft.ApplicationServer.Caching.Core (v18.104.22.168 instead of 22.214.171.124 in the AppFabric Cache).
I've spent the day trying to figure out why my workflow (with an activity that accesses the AppFabric Cache) wasn't working... I just got an the weird error "Message='XAML Node Stream: Missing CurrentObject before EndObject.' Line number '45' and line position '32'."; which I usually get when a class can't be instantiated... however, this time I've traced it to a dll mismatch between my workflow activity library (where the AppFabric Cache access activity lives) and my workflow project.
This leads to my question:
Can Windows AppFabric Caching and Azure SDK live together on the same machine? Meaning, applications or libraries developed against those products. This is because I'd assumed my Azure Relay server and my AppFabric access service (Not the DistributedCacheService itself) would live on the same machine because the Relay server gets data from AppFabric... but I'm having second thoughts about that because of the issues I've seen.
Can someone provide any guidance on this? Are there any best practices for deploying these two technologies which (from their names) I'd assumed should play seamlessly together?
Todas las respuestas
martes, 13 de marzo de 2012 8:14
Please see the article at http://msdn.microsoft.com/en-us/library/windowsazure/gg278344.aspx which provides guidelines on the topic. While not recommended, it is possible to have both on-premise and Azure SDK versions of caching assemblies (1.0 was not supported this way, 1.1 is in default install config) on the same machine, since they are not installed in GAC by default. Please verify that the assemblies in question are not in the GAC, and you've added a reference to the correct set of DLLs.
Applications can be built against one or the other but cannot use both. An app using Azure SDK cache client DLLs will not work against a 1.1 server; you'll need to add the 1.1 client DLLs in references and recompile.
I couldn't gather if it was 126.96.36.199 DLL version you expected and 188.8.131.52 that was loaded incorrectly, or vice versa. Could you please clarify.
martes, 13 de marzo de 2012 11:33
Thanks for the response. I'll check out the article and follow the guidelines.
I'd already built my assemblies to connect to the Windows Server AppFabric Cache which worked fine for both 1.0 and 1.1. I then installed the Azure SDK a couple of weeks ago but didn't reference its assemblies; however, I did reference the Microsoft.ServiceBus dll in some of my assemblies... could that have caused VS to pull in the Azure assemblies? It wasn't until I started having problems in my workflows that I found the conflict.
Finally, I expected to have the 184.108.40.206 dll (which shows up as 1.0.4632 in the VS Add Reference window); but I got the 220.127.116.11; which shows up as 1.0.4617 in the visual studio Add Reference window.
I didn't think about these two conflicting so I didn't monitor what I was doing when adding the Azure SDK install and references to my projects. I'll read the article you mentioned and monitor more carefully...
martes, 13 de marzo de 2012 17:19
As far as I know, service bus assemblies do not have a dependency on cache assemblies, so the possibility you mention does look quite remote to me.
It might be a good idea to select the correct assembly from the path where they are installed in Program Files when adding references, instead of letting Visual Studio do that for you. I generally do not recommend setting 'specific version' for the reference to true, but that might be a good idea in this case. In the end, without 'specific version', your application will resolve the cache assembly from your local app path (unless a version exists in the GAC) so as long as you deploy the right bits, everything should work fine.
You could try opening the .??proj (csproj; vbproj...) file in a text editor and see what the reference is set to. If it turns out you have a reference like this without a version or hint path mentioned, Visual Studio is free to pick up whichever version of the assembly it chooses to next time VS starts.
<Reference Include="Microsoft.ApplicationServer.Caching.Core"> <SpecificVersion>False</SpecificVersion> </Reference>
martes, 13 de marzo de 2012 17:44
Thanks Arijit - I appreciate your help. I've gotten this working by explicitly selecting the WinServer assemblies from the installation directory.