locked
Can the AppFabric Caching dlls shipped with Windows Server AppFabric and the Azure SDK coexist? RRS feed

  • Question

  • Hi,

    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 (v101.0.0.0 instead of 1.0.0.0 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?

    Thanks!


    Thanks, KBW

    Monday, March 12, 2012 12:55 PM

Answers

  • Hi KBW,

    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>

    -Arijit


    Tuesday, March 13, 2012 5:19 PM

All replies

  • Hi KBW,

    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 101.0.0.0 DLL version you expected and 1.0.0.0 that was loaded incorrectly, or vice versa. Could you please clarify.

    -Arijit

    Tuesday, March 13, 2012 8:14 AM
  • Hi Arijit,

    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 1.0.0.0 dll (which shows up as 1.0.4632 in the VS Add Reference window); but I got the 101.0.0.0; 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...

    Thanks!


    Thanks, KBW

    Tuesday, March 13, 2012 11:33 AM
  • Hi KBW,

    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>

    -Arijit


    Tuesday, March 13, 2012 5:19 PM
  • Thanks Arijit - I appreciate your help.  I've gotten this working by explicitly selecting the WinServer assemblies from the installation directory.


    Thanks, KBW

    Tuesday, March 13, 2012 5:44 PM