error CS1504: Source file 'C:\...\ParticleLinearScaleModifier.cs' could not be opened ('Unspecified error ')

This is not just a rant about the how ridiculous that error message is but hopefully, will give youat least  ONE idea on how to fix it (considering its such a vague error i’ll do my best).

In Visual Studio you can move files around within the solution explorer, some how, i have absolutely no idea how, I’d managed to move all of the files, including directory structure into another directory.  However nothing was shown in the solution explorer to be different, i.e. the directory structure looks exactly as it should.  but on going to Windows explorer i found that all the files were in a different location.

Moving these files back and reverting using subversion fixed my problem.  But why do Microsoft put in unspecified errors…?  So helpful Microsoft are :/

Creating a new type

The C# languages types are all derived from the FCL (Framework class library) type: System.Object.  As all types are derived from the Object type and the CLR requires all objects to be created with the “new” operator objects are declared and created as follows:

System.Object obj = new System.Object()

The new operator calculates the number of bytes required by all the instanced fields in the type and all derived types up to and including System.Object.  Every Object added to the heap requires additional members used by the CLR to manage the object – sync block index and the object pointer .  The additional bytes for these members are added to the total size.  The CLR then allocates this memory from the managed heap and then the CLR initializes the type object pointer and sync block index members.  Finally the constructor is called.  Each constructor of the derived types are responsible for initializing the instanced fields of that particular constructors type. Finally a reference to the newly initialized type is returned and stored.

Primitve types

C# reserves certain keywords that represent commonly used types.  These types are known as primitive types.  Primitive types are always synonyms of types described in the FCL.  For instance in the following example exactly the same intermediate language code would be created:

int _integer = 0;                  // Creates a new instance of the System.Int32 type.
int _integer = new System.Int32(); // Creates a new instance of the System.Int32 type.
System.Int32 _integer = new int(); // Create a new instance of the System.Int32 type.

All of the above declarations and initialization are interchangeable.

Keywords are defined by the specific language specification and implemented by the compiler.  The problem with this is that different languages specifications will always vary slightly and have the possibilities to cause confusion when reading code across languages.  For example in C# the long primitive maps to System.Int64 where as in managed C++ the long primitive is treated as an Int32.

Primitive mappings do not change when switching between 32 bit and 64 bit systems using .net as they might do in unmanaged C++ or C.

Primitive type overflow: Checked and Unchecked operations

Consider the following code:

byte _byte = 57;
_byte = (byte) (_byte + 200);

What would the value in _byte be after the second line of execution?

_byte would be equal to 1. Note that the type cast performed in the second line is necessary as the operand values are expanded to Int32 values.

Sometimes this behaviour is desired, but more often than not can cause subtle bugs.  The IL generated by C# will by default have overflow checking turned off, this means the IL code runs slightly faster.  However what if we do need to check for overflows and throw exceptions when they occur?  C# provides “checked” and “unchecked” operators.  The checked operator will throw an OverflowException if an overflow occurs, and the unchecked operator will allow the overflow to occur.  These can also be set in statement blocks.

Checked example:
Byte _byte = 57;
_byte = checked((Byte)( _byte + 200));


This will throw an exception with the message:  ”Arithmetic operation resulted in an overflow.”  Whereas the following code will execute without an error being raised:

Byte _byte = 57;
_byte = unchecked((Byte)(_byte + 200));

Value types: struct

In C# value types are defined using struct.  Value types are allocated on the stack, along with references to objects on the managed heap.  Consider the following code:

struct AValue { int X; }
...
AValue _value = new AValue();
_value.X = 50;
AValue _newValue = _value;
_newValue.X = 100;
Console.WriteLine(_value.X);      // Outputs 50.
Console.WriteLine(_newValue.X);   // Outputs 100.

Here a struct : AValue is defined.  In the main section of the code we create an AValue type called _value which we then copy to the _newValue variable and allocate new space on the thread stack.  This point is important, the fact that we have allocated new space on the stack and copied the members to a completely new instance of the AValue type.  This is a fundamental difference between the use of value types and reference types (see next section for reference types).

Boxing and unboxing value types

Sometimes it may be necessary to use a reference to an instance of a value type.  Consider the following code:

struct SomeVal { public int x; }
class SomeClass
{
public Object _theObject;
public void Get(object param)
{
_theObject = param;
}
}

...

SomeClass _ref = new SomeClass();
SomeVal _val = new SomeVal();
_val.x = 2000;
_ref.Get(_val);

You can see that the SomeClass object requires a reference to an object on the managed heap, however we are trying to pass a value type as a parameter which is stored on the stack.  For the above example to work the value type must be converted to a managed object stored on the heap. Boxing allows us to do this.

Boxing works by allocating memory to the heap required by the value type’s fields (plus the two additional fields required for objects on the managed heap – object pointer and sync block index).  Then the value types fields are copied into the allocated heap memory.  And finally an object reference is returned.  Essentially you are converting you’re value type to a reference to a type on the managed heap.  This can carry some extra overhead in terms of cpu cycles and memory usage as we are allocating extra space on the heap as well as the stack.

Consider the following example (following on from the previous code example):

SomeVal _val2 = (SomeVal)_ref._theObject;

Here we are taking a reference and trying to place it in a value type instance.  For this to work we need to copy fields contained on the managed heap into the value type fields on the stack.  This operation is known as unboxing.

Boxing in some situations can be avoided by using generics.

Reference types

The last type that I haven’t talked about yet is reference types.  Reference types are always allocated on the managed heap. Unlike value types, if you remember which are stored on the thread stack.  When a new reference type is created a memory address is stored on the stack as a reference to the object on the managed heap. Reference types can carry some performance overheads.   Which is why the CLR provides value types as lighter weighted variables.  A type declared using the class keyword is a reference type and a type declared using the struct keyword is a value type (enums are also derived from value types).

That’s all for now.  I’ve been playing around with C# a bit more and have some more interesting findings to post soon.  Watch this space.