locked
SODA Application Sample gets Casting Exception RRS feed

  • Question

  • I have built a HealthVault SODA Client Application using the sample http://msdn.microsoft.com/en-us/healthvault/ee708278.aspx.  I used the Application Configuration Center to create an Application ID and I set some SODA App Rules to require access to the Basic Demographic Information. The last line of code gets a exception: "_message = "Unable to cast object of type 'Microsoft.Health.HealthRecordItem' to type 'Microsoft.Health.ItemTypes.Basic'."

    How can I fix this Sample and get the Basic Information ?

    // Search the health record for basic demographic information.  
    HealthRecordSearcher search = access.CreateSearcher();
    search.Filters.Add(new HealthRecordFilter(Basic.TypeId));
    HealthRecordItemCollection searchResultsGroup = search.GetMatchingItems()[0];
    
    if (searchResultsGroup.Count > 0) {
          Basic info = (Basic)searchResultsGroup[0];
    }
    Monday, February 15, 2010 12:02 AM

Answers

  • Yes, it is confusing. We made a change in naming but didn't realize the ramifications it would have to people using ACC.  We will improve it with our next release, though the solution we want likely won't fit into that release.

    For the rest of the types it's generally more straightforward. The vast majority of them don't currently have multiple versions. For the majority of the rest of them, if you choose the top name in ACC and use the type that is in Microsoft.Health or Microsoft.Health.Itemtypes, you will just get what you want automatically.

    If you're not sure, you can compare the guid in the hover with the class name.TypeId. That will always work.

    I'm sorry that our oversight has caused issues on your side. We'll try not to repeat that in the future.
    • Marked as answer by DonBaechtel Wednesday, February 17, 2010 1:45 AM
    Tuesday, February 16, 2010 11:52 PM
  • THANKS for your help.

    Please make sure that in the next release that ALL of the code, utilities, tools, documentation, samples and blogs ALL use the SAME terminology and that you provide documents on how to migrate from any old terminology to the new.

    The pain of ALL of the conversion, documentation and testing should provide a lesson to avoid making partial conversions to breaking changes in the future.

    Also, in the mean time, how about updating the ACC so that Basic Demographic Information is changed to  Basic Demographic Information V2, and Basic Demographic Information V1 is changed to Basic Demographic Information, so that it agrees with the SDK typeIDs.

    THANKS and Good Luck.
    • Marked as answer by DonBaechtel Wednesday, February 17, 2010 1:58 AM
    Wednesday, February 17, 2010 1:50 AM

All replies

  • Do the following:

    Ensure that you have given access ONLY to the newer version of basic demographic data type in application configuration center for the app.

    When you query, query for BasicV2.TypeId (as against Basic.TypeId).   You may need to refer to the microsoft.healthvault.itemtypes.dll for this.

    Let me know if you still have issues.

    As far as I can tell,  you are seeing this behaviour since you have not referred the itemtypes.dll in your project (so the SDK cannot instantiate the BasicV2 type runtime).



    Raj HealthVault Developer Tool http://xray.getrealconsulting.com
    Monday, February 15, 2010 9:09 AM
  • Hello,

    Can you please let me know your application ID?

    Thanks and Regards,
    Aneesh D.
    Monday, February 15, 2010 7:32 PM
  • I want to access the Basic data, not the BasicV2.

    If Basic is a subclass of HealthRecordItem as indicated by the Basic class metadata,
    public class Basic : HealthRecordItem
    why can't Microsoft.Health.dll cast the Microsoft.Health.HealthRecordItem to a variable of type Basic.

    What is missing from the HealthVault SODA Client Application sample to make the sample code work as intended without the exception?

    How do you cast a Microsoft.Health.HealthRecordItem returned from search.GetMatchingItems to a a record of the specified 'Microsoft.Health.ItemTypes ?
    Monday, February 15, 2010 9:45 PM
  • The AppID for TCA2 is 47318b5f-f9e5-483e-afe0-e2037c465e5.
    I made some chnges to the app to temporarily get around the issue.

    I still do not know How to cast a Microsoft.Health.HealthRecordItem returned from search.GetMatchingItems to a a record of the specified 'Microsoft.Health.ItemTypes ?

    I hope that this helps you find the problem
    Monday, February 15, 2010 9:48 PM
  • I do have a reference to Microsoft.Health.ItemTypes.dll and

     

    using Microsoft.Health.ItemTypes;

     

     

    as indicated in the HealthVault SODA Client Application sample.

    What more do I have to do to cast a Microsoft.Health.HealthRecordItem returned from search.GetMatchingItems to a a record of the specified 'Microsoft.Health.ItemTypes ?
    Monday, February 15, 2010 9:52 PM
  • If it won't cast a 'Microsoft.Health.HealthRecordItem'  to a Basic.TypeId, what makes you think it will work differently with BasicV2.TypeId ?

    Besides, I want the Basic information not the BasicV2 information.
    Monday, February 15, 2010 9:56 PM
  • The application ID you have specified seems to have only 31 digits. I think you missed a digit when copying. Please post the complete Master application ID.

    If the application rules specify access to both Basic and BasicV2 then Shell will return the types as it is. It is then the application's responsibility to treat both the types separately. Here please note that if an item is of Basic type then it cannot be type-casted to BasicV2 from the HealthRecordItem base class. If the application rules specify access to only one of the type then Shell will automatically convert items in the other type to the type needed by the application. Thus the application can treat the item independent of the item's actual version.

    Now I am not sure in which of the above scenario this application comes in. Once I get the application ID we can further investigate this issue.

    Thanks and Regards,
    Aneesh D.
    Monday, February 15, 2010 11:33 PM
  • My masterAppID is 47318b5f-f9e5-483e-afe0-e2037c465e51.

    The application rules specify only Basic Demographic information.

    It is the following cast that is failing:
      search.Filters.Add(new HealthRecordFilter(Basic.TypeId));
      HealthRecordItemCollection searchResultsGroup = search.GetMatchingItems()[0];
      Basic info = (Basic)searchResultsGroup[0];

    This code is from the HealthVault SODA Client Application sample http://msdn.microsoft.com/en-us/healthvault/ee708278.aspx

    I am not trying to cast Basic into BasicV2. I have set the filter for type Basic and I am trying to cast to Basic.

    The Application Configuration Center only allows Basic Demographic Information or Basic Demographic Information (V1). It does not allow Basic V2. BasicV1.TypeId is undefined in the dlls.


    Why is this not working as written in the sample code?
    Tuesday, February 16, 2010 1:34 PM
  • Don,

    Sorry that this is confusing. The long version of how it works is here.

    Unfortunately, we changed our approach on how data types are name (ironically, to make it less confusing...), and ACC hasn't caught up yet. The type that you see as "Basic" in Acc corresponds to BasicV2 in the SDK.

    So, my suggestion is:

    1) Authorize only the Basic type in ACC
    2) Use the BasicV2 type in your code

    That should get you working.
    Tuesday, February 16, 2010 5:24 PM
  • I have spent days fishing around trying to make this MSFT sample code work the way that it is supposed to.
    What about all of the other HealthItemRecord types?
    How long is it going to take me to uncover what the real values should be?
    What are you going to do to properly document the way HealthVault, the acc and the SDk really work?

    Why doesn't HealthVault convert the HealthItemRecord into the Basic type that I requested as the documentation syays that it should.

    There is no definition for BAsicV1 in the SDK dlls, why is that?


    As far as I can tell, none of the HV SDK documentation or online blogs work they way that they say they should without compile errors or runtime exceptions.

    It appears that neith HV online or the ACC are compatible with the most recent SDK.

    The developers at HealthVault seem to have alot of cleanup to do to get all of the code, samples and documentation onto the same page.

    I am not happy with the quality of this SDK.

    I expect the HV developers work quickly to bring these items together in short order.
    Tuesday, February 16, 2010 6:25 PM
  • We have changes planned but not yet scheduled to improve ACC to make this clearer. In the current version, if you hover over a data type it will show you the type id that is associated with that name, and you can correlate that with the type ids of the SDK wrapper classes.

    As Aneesh noted, the type that you get back is based on the configuration of your application in ACC rather than the specific version that you pass in. This is done this way because there are some operations where you don't specify a typeid at all, and the platform needs to know what versions your application can handle. It is possible to override this by adding the specific versions you want to get back to filter.View.TypeVersionFormat, but in general it's much easier if you only set one version in ACC and let the platform deal with it.

    For the wrapper classes, the first version of the Basic type is simply named "Basic". As we version, we add version numbers.  We considered whether we would put version numbers on all types, but that would require all partners to change names in their code for little benefit.

    If you run into specific problems with documentation/samples/blogs where there seem to be problems. I'd love to hear about them.

    Tuesday, February 16, 2010 9:17 PM
  • If the ACC has a Rule called Basic and I use a TypeID called Basic in my code, then I expect to get Basic data back, not a casting exception.

    This is your own sample code that failed. It should have worked without an exception. The fact that it did not should give you a clue that something is wrong with your implementation.

    You haven't answered many of my questions including why ACC has a Type BasicV1 but the SDk does not define it. What's up with that???

    The documentation said something about if I ask for one type, but another is returned then the SDK will convert it automatically. Why didn't that work???

    This process looks to be all messed up. None of the documentation, blogs or samples agree with the way the system actuallly works. The system does not work the way the documenation, blogs and samples indicate that it should. It is not obvious what is needed to make it work. I think that you had better rethink what you are doing, make everything agree on how it works and make it obvious.
    Tuesday, February 16, 2010 9:54 PM
  • I'll try to be clearer.

    The reason you got a casting exception was because your application was configured to accept BasicV2, and therefore the platform gave you a BasicV2. Your code tried to cast it to a Basic, which caused an exception.

    There are two ways to get the behavior you want. The simpest one is configure your application to only deal with the type that corresponds to the wrapper class. I suggest that you choose "Basic demographic information" in ACC and use the BasicV2 wrapper class (Guid 3b3e6b16-eb69-483c-8d7e-dfe116ae6092 if you want to check).

    The second way to do that is to modify your code so that it does the following:

    HealthRecordSearcher search = access.CreateSearcher();
    HealthRecordFilter filter = new HealthRecordFilter(Basic.TypeId);
    filter.View.TypeVersionFormat.Add(Basic.TypeId);
    search.Filters.Add(filter);
    HealthRecordItemCollection searchResultsGroup = search.GetMatchingItems()[0];

    Adding the type id explicitly to the TypeVersionFormat collection will override the platform behavior based on the application configuration. This will work, but you will be working with the old version of the Basic type if you use the code above and it's more code, which is why I recommend setting the application configuration instead.

    The reason why there is no BasicV1 is that we changed our naming scheme to make it clearer and ACC hasn't caught up yet. In this case,

    Basic Demographic Information (ACC) == BasicV2 (SDK)
    Basic Demographic Information V1 (ACC) == Basic (SDK)

    To answer your third question - "The documentation said something about if I ask for one type, but another is returned then the SDK will convert it automatically. Why didn't that work???" - The platform was behaving as expected. Your application configuration declared that it knew how to deal with BasicV2 instances, so that's what came back from GetMatchingItems.

    Tuesday, February 16, 2010 11:09 PM
  • BUT, I configured the ACC for Basic Demographic Information.

    Why isn't Basic Demographic Information in the ACC equal to Basic typeID in the HV SDK ?

    Why is Basic in the ACC = BasicV2 in the SDK? How does anyone figure that out? Where is that documented?

    How come Basic V1 is avaialable in the ACC but undefined in the HV SDK?

    Does all this sound a bit confusing to you?

    What about all the rest of the HV types, what are the conversions from the ACC selection to the HV typeIDs in the SDK?
    Where can I find this information?

    WHY can't the ACC and HV SDK use the same or similar terminology so that the usage is obvious and does not require a non-existent translation table to figure it out ?


    Tuesday, February 16, 2010 11:26 PM
  • Yes, it is confusing. We made a change in naming but didn't realize the ramifications it would have to people using ACC.  We will improve it with our next release, though the solution we want likely won't fit into that release.

    For the rest of the types it's generally more straightforward. The vast majority of them don't currently have multiple versions. For the majority of the rest of them, if you choose the top name in ACC and use the type that is in Microsoft.Health or Microsoft.Health.Itemtypes, you will just get what you want automatically.

    If you're not sure, you can compare the guid in the hover with the class name.TypeId. That will always work.

    I'm sorry that our oversight has caused issues on your side. We'll try not to repeat that in the future.
    • Marked as answer by DonBaechtel Wednesday, February 17, 2010 1:45 AM
    Tuesday, February 16, 2010 11:52 PM
  • THANKS for your help.

    Please make sure that in the next release that ALL of the code, utilities, tools, documentation, samples and blogs ALL use the SAME terminology and that you provide documents on how to migrate from any old terminology to the new.

    The pain of ALL of the conversion, documentation and testing should provide a lesson to avoid making partial conversions to breaking changes in the future.

    Also, in the mean time, how about updating the ACC so that Basic Demographic Information is changed to  Basic Demographic Information V2, and Basic Demographic Information V1 is changed to Basic Demographic Information, so that it agrees with the SDK typeIDs.

    THANKS and Good Luck.
    • Marked as answer by DonBaechtel Wednesday, February 17, 2010 1:58 AM
    Wednesday, February 17, 2010 1:50 AM