Develop Reference

C# Cast works only in debugger

I’m developing a mobile application which among other things, it receives data from medical devices via Bluetooth. To this end, I’m using an Android SDK in JAR via binding to my Xamarin project. Here’s the class that holds the returned data from the decompiled JAR:
package com.contec.jar.contec08a;
import java.util.ArrayList;
public class DeviceData
{
public ArrayList<byte[]> mData_blood = new ArrayList();
public ArrayList<byte[]> mData_oxygen = new ArrayList();
public ArrayList<byte[]> mData_normal_blood = new ArrayList();
}
What is of interest is the mData_blood. Each element of the array list corresponds to a patient. Each byte array is the medical data for each patient. The Xamarin framework makes some changes, i.e. the name of the property becomes MDataBlood.
Problem: when I receive the above class and property, the casting fails BUT NOT in the debugger. Here’s what I mean: the ‘as’ operator that implement the cast fails (returns null) but in the debugger the very same expression correctly shows the data.
What’s more, the ‘is’ operator returns false in runtime (the canDo variable is false) but true in the debugger. I’ve tried all methods of casting I’m familiar with, even using –but not mixing – Android objects. The highlighted line which casts the IList to List produces a nice exception. I’m at a total loss. Any suggestions would be greatly appreciated.
Here's the screenshot from the debugger which illustrates all the above:
Edit1: The MDataBlood[0] evaluates as generic Java object. When reviewing its properties, its isArray is set to true. By checking the decompiled source of the SDK, I determined that is indeed byte array.

In Xamarin, there are some castings that might fail when the objects come from java types. In that cases you should use JavaCast<TResult> instead of a regular casting.
Try this, instead of your current approach:
// Since MDataBlood is exposed as an IList property of MDeviceData,
// we first need to cast it to IJavaObject
var dataBloodRaw = (IJavaObject)dm.MDeviceData.MDataBlood;
// Then we have access to its JavaCast method
var dataBlood = dataBloodRaw.JavaCast<JavaList<byte[]>>();
JavaList<T> extends Java.Lang.Object, so it can be used as the TResult parameter for JavaCast<TResult>. Also, it implements IList, so you should be able to loop through it.
Anyway, if you need a List<byte[]> you can use the casted JavaList for creating it:
var dataBloodList = dataBlood.ToList();
Or, alternatively
var dataBloodList = new List<byte[]>(dataBlood);
Yet another thing you could just try is to Java-cast dataBloodRaw to a JavaList<object> and then loop through its objects, trying to cast each one of them as a byte[].
Plan B
If none of the above works, I suggest you to take a look at this answer where it is suggested to disable linking for Release, which can be done in your project properties:
Keep in mind that a side effect of this last option will be the impact on the final size of your application.

Templated Lists in C#?

I know templates are common within c/c++ however I am currently trying to translate an old VB code our company uses up to a c# equivalent which brings me to my problem....
VB is an type unsafe language so we come across things like
Public Elements As New Collection
so given the line above I need to translate that to a List.. Given that a Collection can be anything from a List to a map I need to template this as efficiently as possible. I was thinking of for first draft ignoring the map option entirely and just making it a List however from my understanding Templates don't truly exist within C#... The below code is what I came up with so far and while it compiles (I have not gotten to a testing point in the rest of the code yet) I don't know if it would actually work...
Public List<ValueType> Elements = new List<ValueType>();
can anyone offer input on if this would work as a generic list where type is determined at input or if I need to change this so the constructor would look more like
Public List<ValueType> Elements = new List<typeof(foo)>();
if the above is confusing I am sorry it is for me as well, and I will try and clarify as questions come in.
this question is no longer relevant, I was able to go into the source of the calling code and determine what variable types that the lists need to support.

C# SQL CLR Project - Public Generic.List items show up as non-public members in debugger

I'm having an issue in a C# SQL CLR project where publicly declared Generic.List items are not showing up as public in the debugger. This is problematic because I'm trying to serialize the object to XML. The real project has some complex objects, but a very simple example would be something like this:
[Microsoft.SqlServer.Server.SqlProcedure]
public static void DoSomething()
{
// the Thing Object has a public property of List<string>
// that is created in the constructor
Thing t = new Thing();
t.Items.Add("test");
t.Items.Add("test2");
// now, if I look at t in the debugger, it has given the
// items list a capacity of 4 and shows the items as
// non-public members (2 with values and 2 that are null)
}
I wanted to post an image from the debugger here, but it appears I cannot do that as a new user...
With all of that said, is this behavior because it is a SQL CLR project? The same code worked fine when developing in a console application (though I guess I could have messed something up when adding it to the CLR project).
Adding additional detail on the Thing object - it includes the following declaration for the Items:
public List<string> Items { get; set; }
Then, in the debugger, the Items just shows Capacity and Count (no actual items or properties for the Items). The actual item instances are listed under Non-Public members.

The Items property itself can never be seen by a debugger, because it is an indexed property, so there isn't a value you can just get for it, and hence examining the value it returns doesn't make sense (like examining the 30th of February or a politician's kept promises; it just doesn't exist).
List<T> uses the DebuggerTypeProxyAttribute attribute to define another class to be used to give a debugger eye view. This class (one internal to mscorlib) has a public Items property that returns an array with a copy of the list's items, so that it looks like you can actually examine the Items property of List<T> when really you are examining the Items property of an object that copies out the items when invoked.
Debuggers don't have to use this approach, so maybe the one you are using doesn't, or there's some other restrictions, but if you are using a debugger that doesn't support DebuggerTypeProxy you can just examine the private member that stores the items in an array (the array will be at least as large as Count, and possibly a bit larger to leave growing room rather than resizing on each Add; you can ignore elements beyond Count - 1).
This has nothing to do with XML serialisation, so whatever problem you are having with that is likely completely unrelated.
Edit:
I see some people are having other problems with XML serialisation and the SQL CLR as per these:
SQL Server not finding serialization assembly
http://connect.microsoft.com/VisualStudio/feedback/details/753005/when-deploying-a-sqlclr-assembly-with-a-generated-xmlserializer-assembly-the-xmlserializer-assembly-should-be-deployed
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/3fa5dce3-b0f3-44f8-9b7b-65439f1c98ae/cannot-deploy-xmlserializers-clr-assemblies?forum=ssdt
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/e6560fa4-76f1-4da2-b795-7926d0743baa/sql-clr-problem-with-xmlserializer?forum=sqlnetfx
Your XML problem is indeed different to your debugger view issue. (I meanwhile am off to add debugger proxies to some of my collection types, I've always figured people would just skip through to the inner members and not care, but you've made me rethink that one).

How to read old version of MongoDb document with new model in code

Lets say my c# model updated while correspondent collection still contains old documents, I want old and new documents to coexist in the collection, while using only new version of c# model to read them. I wish no inheritance is used if possible. So I wonder which of this issues are solvable and how:
there is a new property in c# model which does not present in database. I think it never should be an issue, Mongo knows nothing about it, and it will be initialized with default value. The only issue here is to initialize it with particular value for all old documents, anybody knows how?
one of property has gone from model. I want MongoDb to find out there is no more property in c# class to map the field of old document to, and to ignore it instead of crashing. This scenario probably sounds a bit strange as it would mean some garbage left in database, but anyway, is the behavior possible to implement/configure?
type if changed, new type is convertible to old one, like integer->string. Is there any way to configure mapping for old docs?
I can consider using inheritance for second case if it is not solvable otherwise

Most of the answers to your questions are found here.
BsonDefaultValue("abc") attribute on properties to handle values not present in the database, and to give them a default value upon deserialization
BsonIgnoreExtraElements attribute on the class to ignore extra elements found during deserialization (to avoid the exception)
A custom serializer is required to handle if the type of a member is changed, or you need to write an upgrade script to fix the data. It would probably be easier to leave the int on load, and save to a string as needed. (That will mean that you'll need a new property name for the string version of the property.)

Can you use the same Enum in multiple entities in Linq-to-SQL?

In my persistence layer, I've declared a load of Enums to represent tables containing reference data (i.e. data never changes).
In Linq2SQL, I am able to set the type of an entity property to an enum type and all is well, but as soon as I set a second entity's property to use the same enum type, the Code Generator (MSLinqToSQLGenerator) start generating an empty code file.
I assume that MSLinqToSQLGenerator is quietly crashing. The question is why, and are there any work-arounds? Anyone else experienced this problem?

Is your enum by any chance in a file named the same as the dbml? There is a bug in 3.5 (fixed in 4.0) where conflicts cause an empty file. Oddly, usually moving the using directives (and right-click; run custom tool) fixes it.
So if you have "foo.dbml" and your own "foo.cs" (in the same folder) with:
using System;
namespace MyNamespace {
}
it will break (generate an empty foo.designer.cs). If you have:
namespace MyNamespace {
using System;
}
it will work. I'm not kidding. Likewise, renaming "foo.cs" to "bar.cs" (and right-click, run custom tool) will fix it.

Oddly, I've discovered that this behavior only occured with an Enum named "GrantType". As soon as changed the name of the enum, the generator started working again.