locked
WebApplicationUtilities.LoadPersonInfoFromCookie returning null when HealthVault dll loaded in GAC RRS feed

  • Question

  • My Goal:
    I have several sites that use the Microsoft.Health.dll. I'd like to install the dll in the GAC so I don't have to make a separate copy of the dll and place it in the bin folder for each site.

    The Problem:
    When using HealthVault I've found that Microsoft.Health.dll must be copied directly into the local bin directory in order to use the returned PersonInfo value returned from WebApplicationUtilities.LoadPersonInfoFromCookie(). If it's not copied locally, the PersonInfo cookie is never set and will always return null. The code below works great when there is a local copy of the Microsoft.Health.dll file in the web sites bin folder. However, if the dll is loaded into the GAC and removed from the bin folder, the LoadPersonInfoFromCookie() call always returns null. How can this be fixed / is there a workaround?

    My Code:
    public static PersonInfo healthVaultPersonInfo
    {
         get { return WebApplicationUtilities.LoadPersonInfoFromCookie(HttpContext.Current); }
    }

    Friday, May 1, 2009 6:01 PM

Answers

All replies

  • I dont have a reason / workaround for the behaviour you are seeing.

    But I would like to share my 2 cents so that you can check if this approach itself should be used.

    I understand the ease of deployment you are going to get by avoiding having to copy the dlls to each application.  But think about this:  Time passes by... Swine Flu gets eradicated... and Microsoft thinks it is time to release new types and deprecates few existing types you are using - (the old item type names gets renamed in such case in SDK).  It may then happen that you have a new application that needs access to a new type.  At this point you are stuck.

    If you deploy the new SDK to GAC so that you can support the new type for the application, the other existing application will break since the name of one of the deprecated type that the application is still using would have change.  I think this problem would definetly offset the convinience that you gain by copying few dlls to each app.

    Hence I would recommend you against this approach. But  in case you still think GAC is the way to go in your case, I can try to repo the problem...

    HTH

    Raj


    Raj HealthVault Developer Tool http://xray.getrealconsulting.com
    • Edited by Rajesh CKR Friday, May 1, 2009 6:26 PM
    Friday, May 1, 2009 6:21 PM
  • We generally don't recommend installing in the GAC-- is there a reason you must use the GAC?
    Wednesday, May 13, 2009 8:44 PM