text: Random notes from a developer...
  The posts on this weblog are provided "AS IS" with no warranties, and confer no
  rights. The statements and opinions expressed herein are my own and are not made
  on behalf of my employer.
  Folks,:)
  See you later...
  Hi Folks...
  The 1st ever Microsoft Mobile & Embedded Developer Conference in India – MEDC-India 2006 – was held at Bangalore’s Grand Ashok Hotel during the 4th-6th April 2006.
  Aarthi and I delivered a session on Creating Custom Controls For Managed Code With Designtime Support In Visual Studio 2005, targeted at folks indulging in custom control development on .NET CF.
  We enjoyed delivering the session and the response from you guys was awesome. It was really nice talking to you guys. Thank you for all the feedback. We are looking forward to meeting you again and please keep the feedback coming in. Please also feel free to contact me at parthad at microsoft dot com if you need any help from us.
  In case you want the session material, it is attached (MOB301 - MEDC2006.zip). It contains the slides as well as the demos and walkthroughs.
  On a lighter note, we did take a couple of photos. Here is one of them:
  The guy closest to the camera is Anand. The 13 year old kid is Aarthi. Partho is on her left. Sriram on her right. Varada on Sriram's right. On Partho's left is Amit and on his right is Gopinath.
  Oh another thing... We met the great Doug Boling. The guys is simply awesome - delivering 5 back-2-back sessions in a single day - all hardcode WinCE kernel related! Manav and I had beer with him and talked about everything from why Hillary Clinton would/wouldn't become the President to what sux in Visual Studio 2005!
  Thats all for now... See you in a while!
  The title of this post may make it sound like a movie. But it ain't. This is a contemporary post noir set on the devices of a gritty, yet colorful SQL Server neighborhood... :D (That was gross, I concur! Hopefully the meat of the post will have some substance and better humor than its opening line)
  The reason for this post was is the following question posted on one of our internal Data on Devices related aliases..
  As you have noticed, we have a rich data-on-devices story with Visual Studio 2005. A lot of work went into this area since Visual Studio 2003 and data-on-devices story is now on par with the desktop data scenarios. Which means that the answer to the above question needs to be broadcasted to a much bigger audience...
  Here it is, from Laxmi Narsimha Rao, my colleague from SQL Server 2005 Mobile Edition team:
  Let me know if you need some more info and/or other clarifications on the above topic. In fact any topic on Data-on-Devices.
  As a side note, I own the Visual Studio for Devices, Data components and I do have plans for a few posts on Data-on-Device. But if there is something specific that you want me to make a post on, I'd be glad. Just let me know...
  See you then, in my next post...
  Hi...
  I am back and it’d have been sooner if not for ELDS :( Never mind that. As many of you have already noted, with Visual Studio 2005 there have been radical changes in the way designtime code is written for .NET Desktop/CF 2.0. These changes in the .NET CF Designtime architecture do break backward compatibility: .NET CF 1.0 Designtime code will refuse to even compile as .NET CF 2.0 Designtime code. But at the same time we believe these changes will:
  Also some of you have asked whether there are any plans for a v1.0 Designtime to v2.0 Designtime upgrade story. There is definitely something up in the air – we have started thinking about it! As of now I do not know exactly how/when it will shape up. But before we release it and so that you are able to take better advantage of the power you wield with .NET 2.0 Designtime, I highly recommend that you take a very detailed pass through Extending Design-Time Support. This is a thorough documentation of .NET 2.0 Designtime, complete with a variety of walkthroughs, samples and lot of other resources. Understanding this is the key to understanding .NET CF 2.0 Designtime. Believe me when I say that the .NET CF 2.0 Designtime is simply built on the .NET 2.0 Designtime. We do nothing special and neither do we get anything special from the .NET Framework Designtime team, just because they happen to sit next door to us :)
  There seems to be a little bit of confusion all around on how folks ought to author designtime code for .NET CF 2.0. To help clear this confusion, I am going to temporarily suspend my currently running blog thread on .NET Framework Designtime. I will resume it once I am done laying out some information on how to tackle the .NET CF 2.0 Designtime and the VSD WinForms designer.
  I am planning to make divide this series into 3 more posts. Next post will be on designtime assemblies (XMTA/AsmMeta) and why they are critical to the .NET CF 2.0 Designtime. In the post after I am going to build a .NET CF custom control and its designer. And in the last post, I will provide tips on debugging .NET CF 2.0 Designtime code. Let me know if you need me to cover other topics.
  See you soon...
  The other day I was investigating an issue that finally boiled down to incorrect usage of System.Reflection & System.Reflection.Emit APIs (SR & SRE hereafter) to analyze Generic types. We were using Type.IsGenericParameter instead of using Type.IsGenericType. During investigation, what made things worse is that each time I went through the first paragraph of their respective help pages, I got more confused. Then I decided to read the Remarks section of the help pages and I was hopelessly lost because it seemed to be written in a dialect of English that I didn’t speak!
  Do you know the difference between Type.IsGenericParameter and Type.IsGenericType? The difference between Generic Type Parameter and Generic Type Argument perhaps? How about Closed Constructed Generic Method and Open Constructed Generic Method? These are a part of some subtle terminology introduced into .NET Framework with Generics. Using SR & SRE without a clear understanding this terminology is only going to land you into trouble. You are going to introduce bugs into your code and you will have a really hard time debugging your own code! Just like me!
  It is all there in MSDN but it is highly confusing at the first glance! So I decided to get done with this for good. I spent a good 3 hours going over Generics terminology in .NET Framework in MSDN. This is a gist of my understanding. I am all clear now. You should be too before you begin using SR and SRE.
  Consider the followign code snippet. The invariant conditions are shown in the comments below it.
  public class Base<T, U>{ public static T M1Base(U u) { return default(T); }}public class Derived<V> : Base<string, V>{ public G<Derived<V>> F; public class Nested { void M1Nested() { } } public static void M1Derived<W>() { }}public class G<T> { } /*Type: Derived<V> IsGenericType: True IsGenericTypeDefinition: True ContainsGenericParameters: True IsGenericParameter: FalseType: Base<string, V> IsGenericType: True IsGenericTypeDefinition: False ContainsGenericParameters: True IsGenericParameter: FalseType: Array of Derived<int> IsGenericType: False IsGenericTypeDefinition: False ContainsGenericParameters: False IsGenericParameter: FalseType: Type parameter T in Base<T> IsGenericType: False IsGenericTypeDefinition: False ContainsGenericParameters: TrueIsGenericParameter: TrueType: Field Derived<V>.F IsGenericType: True IsGenericTypeDefinition: False ContainsGenericParameters: TrueIsGenericParameter: FalseType: Nested IsGenericType: True IsGenericTypeDefinition: True ContainsGenericParameters: True IsGenericParameter: FalseMethod: T Base<T, U>.M1Base(U u) IsGenericMethod: False IsGenericMethodDefinition: False ContainsGenericParameters: TrueMethod: void Derived<V>.M1Derived<W>() IsGenericMethod: True IsGenericMethodDefinition: True ContainsGenericParameters: TrueMethod: void Derived<V>.M1Derived<int>(); IsGenericMethod: True IsGenericMethodDefinition: False ContainsGenericParameters: TrueMethod: void Derived<string>.M1Derived<int>() IsGenericMethod: True IsGenericMethodDefinition: False ContainsGenericParameters: False*/
  If you want to learn more about Reflection & Generics in .NET Framework here are some references:
  Type.IsGenericType Property help page contains an error in the Example-Invariants table. Armed with the above knowledge find it out and let me know! :)
  That's all for now... See you in my next post!
  For a while now, I have been studying the .NET Framework Designtime Infrastructure. Not only because I now own the VSD WinForms and Data designers. But also because the design & architecture of this piece is quiet fascinating… What is the .NET Framework Designtime Infrastructure.? It is the guts of the Visual Studio designer that lets you rapidly design and build rich Windows Forms UI.
  In this series, I will dump my understanding of the .NET Framework Designtime. We will also progressively build an application that can design Windows Installer UI. Our application will also persist the UI in a Windows Installer XML Source file (.wxs) that you can readily use in your WiX projects. The first part of the series will be an introduction to the .NET Framework Designtime. Nothing much explained but a lot outlined. So here goes…
  The term designer used here is not the same as VS WinForms Designer that you see when you create a new windows application. What you see is really the design surface provided by VS acting as the designer host.
  Earlier, in the MFC/ActiveX worlds, the logic for designtime behavior of a component was hardcoded into the tool (a.k.a. IDE) that provided the design surface – meaning, it was the IDE and not the MFC/ActiveX component that was responsible for providing its (the component’s) designtime behavior. This also meant that different IDEs offered their own designtime environments for components, and with different user interfaces and capabilities. And since an IDEs fixed feature set cannot account for the needs of all components, ActiveX/MFC components had only a limited level of custom designtime support.
  In .NET Framework world though, the framework provides every component with its own runtime (obviously!) and designtime behaviors. And just like how the runtime behavior of a component can be customized/extended (e.g. subclassing), so can the designtime behavior of the component be customized & extended by IDEs. This means that every .NET Framework component contains logic for how it behaves and runtime and at designtime. The IDE simply extends, configures and exposes this designtime behavior to the developer. There are of course some services and behaviors that are very strongly tied to the IDE that hosts the design surface (e.g. exposing the design surface, context menus, toolbox interaction etc.). These services are implemented by the host IDE and the component uses these services at designtime after obtaining them from the host IDE through well defined interfaces.
  Of course when I say that every component provides both its runtime and designtime behavior, I don’t mean that every component needs to contain the code for its designtime behavior and the code for its runtime behavior in the same class or even the same assembly. Although this is possible, in most cases it is not practical. Doing so would simply bloat the runtime code which necessarily needs to be as slim and trim as possible. Note that every byte loaded into memory has a cost associated with it (working set, time to JIT etc.). As an example, consider System.Windows.Forms.Control. Its runtime code is in System.Windows.Forms.Control, System.Windows.Forms.dll and its designtime code in System.Windows.Forms.Design.ControlDesigner, System.Design.dll. Use Reflector to peek into the implementations of both and you will get an idea of the bloat. Just going by lines of code Control.cs is 19217 lines and ControlDesigner.cs is 3842 lines which is ~20% code bloat.
  So more often than not, designtime and runtime code separation is employed. This basically means that the designtime code is located on a different class/assembly than the runtime code, like in the System.Windows.Forms.Control example. And the runtime code provides pointers to the designtime code using one or more attributes (e.g. DesignerAttribute). At designtime the .NET Designtime Infrastructure then just looks up the designtime attributes on the component, locates and executes the designtime code to allow us to design the component.
  Things get a little bit trickier when you are designing .NET CF components. The .NET CF usually executes on memory constrained devices so it needs to be highly trimmed. Since attributes contribute to size of metadata and therefore overall size of the assembly, the usage of attributes in .NET CF code cannot be as lavish as that on the desktop. Because of this the .NET CF doesn’t support any of the designtime attributes. To work around this the VSD WinForms designers uses the XMTA and AsmMeta files. I will elaborate on the XMTA/AsmMeta files in a future blog but for now, in short, the pointers to the designtime code reside in the AsmMeta assemblies. So at designtime for a .NET CF component, the VSD WinForms designer locates the AsmMeta assembly for the component, reads the pointer to the designtime code from it, loads and executed the designtime code to allow us to design the .NET CF component.
  How do you typically use the IDE to design a windows forms application? For starters, you create a class that derivers from Form (or UserControl or Component). Then you open that class in design view and drag-n-drop other controls and/or components on it, edit the various properties and hook up handlers for the various events. While you are designing the application the IDE may look like the following:
  As usual, the details hidden from the user are a lot more complicated. The following diagram will give you an idea of what is actually going on under the hood. A sound understanding of the pieces in the diagram is the key to understanding the .NET Framework Designtime Infrastructure. In this series I will be explaining each of these pieces.
  In the case of the desktop .NET Framework both designtime and runtime code is executed by the desktop CLR. But for .NET CF, the designtime code is executed by the desktop CLR (hosted inside Visual Studio) while the runtime code is executed by the device CLR. This implies that for .NET CF components the designtime code targets the desktop .NET Framework while the runtime code targets the .NET CF.
  Also the architecture of .NET Designtime is such that during designtime the .NET Framework components (well controls really!) draw themselves! Meaning at designtime, in addition to the component's designtime code, its runtime code is also executing! Meaning during designtime, since Visual Studio has loaded only the desktop CLR, device controls that require the device CLR cannot run! All device components belong to the following two categories:
  The above is the basis for the .NET CF Designtime.
  Moreover the set of Properties/Attributes/Events exposed by a .NET CF component is usually, but not always, a subset of the set exposed by the corresponding desktop .NET component. This needs to be reflected during the designtime – we cannot show a desktop only P/A/E while designing a .NET CF component. To achieve this VSD WinForms designer uses the XMTA/AsmMeta trick that is based on the P/A/E filtering natively supported by the .NET 2.0 designtime.
  Central to the P/A/E filtering architecture is the TypeDescriptor. The v2.0 .NET designtime doesn’t use System.Reflection to obtain a component’s metadata. Instead the TypeDescriptor is used. Using it, you can remove all of the components native metadata (ones that you get by System.Reflection) and replace them with your choice of metadata! More on this in a subsequent post…
  Thats all this post. Next post will dig deeper into the Designtime Environment diagram and start constructing our WiX UI designer.
  Hi Folks…
  It’s been a long long time since my last post. What have I been doing since then? Hmmm… apart from ELDS here is that list:
  But these are of course very poor excuses for not coming up with a single post in 6 months. But I am going to change that esp. since engaging and spending time with you guys is one of the focus points for my next and future career reviews :-)
  Getting back to the topic on hand…
  Object Test Bench has been out for many months now. The final release will have very few changes from Beta 2. And we are looking forward to enhancing it for v2. Here is your chance to shape the v2 of Object Test Bench.
  How have you liked OTB so far? What is the weirdest way you have used it? Which feature of OTB did you hate the most? What are the roadblocks you have hit? What enhancements would you like us to make in v2? What do you think it will take for OTB to be a killer component?
  Personally, I would like to see the following in v2.
  Basically OTB should graduate to a full blown feature helping in enterprise software development. But note that I am no longer in the team that owns OTB, so you should not be surprised if OTB v2 turns our completely different from what I think it should :-)
  We are eagerly waiting for your feedback, criticisms, comments and ideas for v2. You may send them through any of the channels below:
  Last but not the least you may contact me and I will personally go and deliver your message to the J# team. (They are sitting just next door to me anyways :-)
  See you in the next post…
  Hi Folks…
  How often have you surfed the web, wanting to learn about a new whiz-bang .NET Framework API that you just heard of? Often right? I for one have found myself do this very frequently…
  Surfing the web usually comprises of running a web search on the whiz-bang keywords that got you in the mood in the first place. With a bit of luck, the search engine returns a host of sites that contain documentations/tutorials/samples/snippets on the API you are looking for. There are sites like The Code Project, DevX.com, DevHood that are doing a great job in introducing the API to audiences at all levels. Then there also sites like the one you are currently on – the blogs. After reading the documentation/comments on these sites you aren’t really done till you actually try out the code snippets/samples – right?
  Here is when OTB can help you out! You no longer need to copy the sample, build it and then debug it before you can get a grip on what’s the API is really about. With as little work as starting the IDE and creating a Zero Impact project, OTB will help you understand the API visually. This is what I am going to show you today. And note that, the API need not really be an .NET Framework API. It could be any 3rd party API written for the .NET platform.
  One of the killer features that .NET Framework offers the compiler writers is the Reflection.Emit namespace. Now I want to learn about that. So I run a web search with “Reflection.Emit dynamically generated code”. And the first hit on one of the popular search engines is an excellent blog by my fellow Microsoftie, Mike Stall. That’s a good hit – apart from demonstrating how to generate code dynamically, Mike also demonstrates how to debug the dynamic code!!! Ain’t that really totally cool!!!
  /*01*/ // Sample of emitting debugging information for dynamic modules/*02*/ // Reflection emit example adopted from*03*/ using System;/*04*/ using System.Reflection;/*05*/ using System.Reflection.Emit;/*06*/ using System.Threading;/*07*/ using System.Diagnostics.SymbolStore;/*08*/ /*09*/ public class EmitHelloWorld/*10*/ {/*11*/ static void Main(string[] args)/*12*/ {/*13*/ // create a dynamic assembly and module /*14*/ AssemblyName assemblyName = new AssemblyName("HelloWorld");/*15*/ /*16*/ AppDomain appDomain = Thread.GetDomain();/*17*/ AssemblyBuilder assemblyBuilder = appDomain.DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.RunAndSave);/*18*/ /*19*/ ModuleBuilder module = assemblyBuilder.DefineDynamicModule("HelloWorld.exe", true); // <-- pass 'true' to track debug info./*20*/ /*21*/ // Tell Emit about the source file that we want to associate this with. /*22*/ Guid emptyGuid;/*23*/ emptyGuid = Guid.Empty;/*24*/ ISymbolDocumentWriter doc = module.DefineDocument("Source.txt", emptyGuid, emptyGuid, emptyGuid); /*25*/ /*26*/ // create a new type to hold our Main method/*27*/ TypeAttributes typeAttributes;/*28*/ typeAttributes = TypeAttributes.Public | TypeAttributes.Class;/*29*/ TypeBuilder typeBuilder = module.DefineType("HelloWorldType", typeAttributes);/*30*/ /*31*/ // create the Main(string[] args) method/*32*/ MethodAttributes methodAttributes;/*33*/ methodAttributes = MethodAttributes.HideBySig | MethodAttributes.Static | MethodAttributes.Public;/*34*/ Type voidType = Type.GetType("System.Void");/*35*/ Type[] parameterTypes;/*36*/ parameterTypes = new Type[] { typeof(string[]) };/*37*/ MethodBuilder methodbuilder = typeBuilder.DefineMethod("Main", methodAttributes, voidType, parameterTypes);/*38*/ /*39*/ // generate the IL for the Main method/*40*/ ILGenerator ilGenerator = methodbuilder.GetILGenerator();/*41*/ OpCode genericOpCode;/*42*/ /*43*/ // Create a local variable of type string, and call it xyz /*44*/ Type stringType = Type.GetType("System.String"); /*45*/ LocalBuilder localXYZ = ilGenerator.DeclareLocal(stringType); /*46*/ localXYZ.SetLocalSymInfo("xyz"); // Provide name for the debugger. /*47*/ /*48*/ // Emit sequence point before the IL instructions. This is start line, start col, end line, end column, /*49*/ /*50*/ // Line 2: xyz = "hello"; /*51*/ ilGenerator.MarkSequencePoint(doc, 2, 1, 2, 100);/*52*/ genericOpCode = OpCodes.Ldstr;/*53*/ ilGenerator.Emit(genericOpCode, "Hello world!");/*54*/ genericOpCode = OpCodes.Stloc;/*55*/ ilGenerator.Emit(genericOpCode, localXYZ);/*56*/ /*57*/ // Line 3: Write(xyz);/*58*/ Type sysConsoleType = Type.GetType("System.Console");/*59*/ parameterTypes[0] = typeof(string);/*60*/ MethodInfo infoWriteLine = sysConsoleType.GetMethod("WriteLine", parameterTypes);/*61*/ ilGenerator.MarkSequencePoint(doc, 3, 1, 3, 100);/*62*/ genericOpCode = OpCodes.Ldloc;/*63*/ ilGenerator.Emit(genericOpCode, localXYZ);/*64*/ genericOpCode = OpCodes.Call;/*65*/ ilGenerator.EmitCall(genericOpCode, infoWriteLine, null);/*66*/ /*67*/ // Line 4: return; /*68*/ ilGenerator.MarkSequencePoint(doc, 4, 1, 4, 100);/*69*/ genericOpCode = OpCodes.Ret;/*70*/ ilGenerator.Emit(genericOpCode);/*71*/ /*72*/ // bake it/*73*/ Type helloWorldType = typeBuilder.CreateType();/*74*/ /*75*/ // run it/*76*/ MethodInfo mainMethod = helloWorldType.GetMethod("Main");/*77*/ object[] parameters;/*78*/ parameters = new string[] { null };/*79*/ mainMethod.Invoke(null, parameters);/*80*/ /*81*/ // set the entry point for the application and save it/*82*/ assemblyBuilder.SetEntryPoint(methodbuilder, PEFileKinds.ConsoleApplication);/*83*/ assemblyBuilder.Save("HelloWorld.exe");/*84*/ }/*85*/ }
  For ready reference above is the source code from Mike’s blog, that we are going to study visually. Here we go!
  This section assumes that you know your way around Object Test Bench. If not, please go through my previous blog and/or keep it open for reference.
  (Line 14) In the CV, navigate to System.Reflection.AssemblyName. Right click and from the CI menu, select the constructor with a string parameter. The CI dialog will appear. Enter assemblyName as the instance name and "HelloWorld" as parameter and press OK. You will then have the assemblyName object on the test bench. Go ahead and explore it using the enhanced datatips.
  (Line 16) In the CV, invoke the GetDomain static method on the System.Threading.Thread class. In the MCR dialog that comes up, save the return value on the test bench as appDomain. In the test bench, right click on appDomain and invoke the DefineDynamicAssembly method on it with assemblyName and System.Reflection.Emit.AssemblyBuilderAccess.RunAndSave as parameters. Using the MCR, save the return value as assemblyBuilder.
  (Line 19) Invoke the DefineDynamicModule method on the assemblyBuilder object with "HelloWorld.exe" and true as parameters. Save the return value as module.
  (Line 22) Create the emptyGuid object by executing “Guid emptyGuid;” in IW. Note that emptyGuid is already set to System.Guid.Empty. Invoke the DefineDocument method on the module object with "Source.txt" as the first parameter. For the remaining 3 parameters select emptyGuid from the parameter dropdown list. Save the return value as doc.
  (Line 27) Create the typeAttributes object by executing “System.Reflection.TypeAttributes typeAttributes;” in the IW. In the test bench, hover over the typeAttributes object to get the enhanced datatips. Using the enhanced datatips and set the value of typeAttributes to “System.Reflection.TypeAttributes.Public | System.Reflection.TypeAttributes.Class”. Invoke the DefineType method on the module object with "HelloWorldType" and typeAttributes as parameters. Save the return value as typeBuilder.
  (Line 32) Create the methodAttributes object by executing “System.Reflection.MethodAttributes methodAttributes;” in the IW. Using the enhanced datatips, set methodAttributes to “System.Reflection.MethodAttributes.HideBySig | System.Reflection.MethodAttributes.Static | System.Reflection.MethodAttributes.Public”. Invoke the GetType static method on the System.Type class with "System.Void" as parameter. Save the return value as voidType. Create the parameterTypes object by executing “Type[] parameterTypes;” in the IW. Using the enhanced datatips, set parameterTypes to “new Type[] { typeof(string[]) }”. Invoke the DefineMethod on typeBuilder with "Main", methodAttributes, voidType, parameterTypes as parameters. Save the return value as methodbuilder.
  (Line 40) Invoke the GetILGenerator method on the methodbuilder object. Save the return value as ilGenerator. Create the genericOpCode object by executing “System.Reflection.Emit.OpCode genericOpCode;” in the IW.
  (Line 44) Invoke the GetType static method on the System.Type class with "System.String" as parameter. Save the return value as stringType. Invoke the DeclareLocal method on the ilGenerator object with stringType as parameter. Save the return value as localXYZ. Invoke the SetLocalSymInfo method on the localXYZ object with "xyz" as parameter.
  (Line 51) Invoke the MarkSequencePoint method on the ilGenerator object with doc, 2, 1, 2, 100 as parameters. Using the enhanced datatips, set genericOpCode to System.Reflection.Emit.OpCodes.Ldstr (Important: Please see the notes section below!). Invoke the Emit method on the ilGenerator object with genericOpCode and "Hello world!" as parameters. Using the enhanced datatips, set genericOpCode to System.Reflection.Emit.OpCodes.Stloc. Invoke the Emit method on the ilGenerator object with genericOpCode and localXYZ as parameters.
  (Line 58) Invoke the GetType static method on the System.Type class with "System.Console" as parameter. Save the return value as sysConsoleType. Using the enhanced datatips, parameterTypes[0] to typeof(string). Invoke the GetMethod method on the sysConsoleType object with "WriteLine", parameterTypes as parameters. Save the return value as infoWriteLine. Invoke the MarkSequencePoint method on the ilGenerator object with doc, 3, 1, 3, 100 as parameters. Using the enhanced datatips, set genericOpCode to System.Reflection.Emit.OpCodes.Ldloc. Invoke the Emit method on the ilGenerator object with genericOpCode and localXYZ as parameters. Using the enhanced datatips, set genericOpCode to System.Reflection.Emit.OpCodes.Call. Invoke the EmitCall method on the ilGenerator object with genericOpCode, infoWriteLine, null as parameters.
  (Line 68) Invoke the MarkSequencePoint method on the ilGenerator object with doc, 4, 1, 4, 100 as parameters. Using the enhanced datatips, set genericOpCode to System.Reflection.Emit.OpCodes.Ret. Invoke the Emit method on the ilGenerator object with genericOpCode as parameter.
  (Line 73) Invoke the CreateType method on the typeBuilder object. Save the return value as helloWorldType.
  (Line 76) Invoke the GetMethod method on the helloWorldType object with "Main" as parameter. Save the return value as mainMethod. Create the parameters object by executing “object[] parameters;” in the IW. Using the enhanced datatips, set parameters to “new string[] { null }”. Invoke the Invoke method on the mainMethod object with null, parameters as arguments.
  Yooooohooooo!!! #1: At this point the break point in source.txt that you had set earlier should be hit. (Here is how it looks on my machine) On you step out of the Sources.txt file, you will get the MCR dialog informing you that the call was successful. (Here is how my IDE looks at this point)
  (Line 82) Invoke the SetEntryPoint method on the assemblyBuilder object with methodbuilder, System.Reflection.Emit.PEFileKinds.ConsoleApplication as parameters. Invoke the Save method on the assemblyBuilder object with "HelloWorld.exe" as parameter.
  Yooooohooooo!!! #2: If you go and examine the project output directory, you can see HelloWorld.exe and HelloWorld.pdb sitting. What’s more, you can open HelloWorld.exe as a project and on pressing F11, the control will step into Sources.txt.
  A lot about Reflection.Emit? Yes of course! But learning Reflection.Emit isn’t the point I am trying to make with this blog. In this blog I have outlined a generic procedure that you employ to visually study and explore any 3rd party API for the .NET platform. Just like the Class Designer helps you get a static view of the API you are studying using, OTB helps you get the dynamic view of that API.
  Because of a bug in Visual Studio 2005 Beta 2, it will not be possible to set genericOpCode directly to System.Reflection.Emit.OpCodes.Ldstr using the enhanced datatips. As a work around you can set genericOpCode to ( System.Reflection.Emit.OpCode )Type.GetType( "System.Reflection.Emit.OpCodes" ).GetField( "Ldstr" ).GetValue( null ) using the enhanced datatips. This bug has been fixed in the post Beta 2 builds. So you can use the direct method in Visual Studio 2005 RTM.
  (To be concluded...)
  Hi folks…
  This blog was due a long time back… I haven’t been able to get down to it so far because of multiple reasons, first of which is that I suffer from a chronic case of ELDS: Extreme Laziness Disorder Syndrome :-). Second, I have just moved into a new team – Visual Studio for Devices. I have been busy doing the transition work and oh boy, there is still a lot to be done!
  Third reason, a genuine one, is that I have been wondering about the format of this blog. Since this is a User’s Manual, obviously there needs to be lot of pictures and illustrations. But too many of them will make the blog too big to sit through! At this point I came across the WinkTM. This is a fantastic tool for creating animated illustrations. All SWF tutorials in this blog are created using that tool, except the sections with the enhanced datatips. Satish – great job and thanks!
  In this blog, I will take you through the various features of OTB. The
  image in each section points to an animated tutorial for that section. Please note this blog is not the official OTB documentation. The official document is here.
  The above context menus are populated dynamically with the constructors, static and instance methods for each CodeType/object. The methods inherited by the CodeType from its parent hierarchy appear in the Inherited Methods group. Also only methods/constructors that conform to certain restrictions appear on the context menus. Here is an example.
  Right click on a CodeType in the CV or CD to obtain the context menu. For each CodeType recognized by OTB, a Create Instance submenu will be available on the context menu, if the CodeType has at least one constructor recognized by OTB.
  On clicking on one of the menu items, OTB will display a dialog like the following:
  You can then enter the values of each parameter that you want to pass to the method in the parameter entry grid. For primitive types, you can type in arbitrary values (e.g. for a string, you can enter any arbitrary string in the value cell). For both primitive and non-primitive types, the dropdown in the value cell lists the available values. The available values consist of the following:
  · Default values, if any. (E.g. default values for Boolean are false and true. For an enum type, the default values are all the defined enumerations)
  · At most 5 most recently used values for primitive types.
  · All objects in the test bench whose types are the same as the parameter type or a subtype of the parameter type.
  Once you are done entering all the parameters, press OK and barring any failures/exceptions, you should have an object on the test bench.
  A CodeType is not recognized by OTB if it doesn’t meet these conditions. E.g. OTB v1 does not recognize generic types. You will not be able to use OTB features on unrecognized CodeTypes. Although that you can create instances of most classes and structs, you cannot create instances of abstract classes, arrays, delegates, interfaces, enums etc.
  A constructor is recognized by OTB subject to these conditions. OTB will not display or invoke constructors that it cannot recognize.
  The CV/CD context menu for a recognized CodeType will also include the Invoke Static Method submenu. This menu lists all the static methods of the CodeType, subject to these restrictions. The static methods inherited from the parent hierarchy are grouped under Inherited Methods submenu. CodeTypes are recognized subject to the same conditions described in the Create Instance section above.
  Clicking on one of the items in the Invoke Static Method menu will throw up a dialog box similar to the Create Instance dialog box, except that the Name field will not be present. After entering the parameters and press OK and OTB will invoke the method for you and return the result to you as described in the Method Call Result section below.
  Right clicking on an object on the test bench will bring up the Invoke Method submenu. This menu lists all the methods that can be invoked on the object, subject to these restrictions. The methods inherited from the parent class are listed under the Inherited Methods menu. For J# and VB, this list of methods includes the static methods of the CodeType also. For C# the methods listed are the instance methods only.
  The test bench can contain objects are actually references to arrays, interfaces, abstract classes, enums and delegates apart from classes and structs. You can invoke methods on any of these.
  To invoke one of the instance methods, click on the respective item in the Invoke Method menu and follow the procedure described in the Invoke Static Method section.
  Assuming there are no errors/failures after you invoke a method (static or instance), there are two cases. First, if the return type of the method is void, a dialog will be shown informing you that the method call succeeded. Optionally you can choose to reinvoke the method with different parameters by clicking Retry.
  If the return type of the method is not void, following dialog box will be thrown up:
  At this point you can choose to save the return value onto the test bench. You can also choose to reinvoke this method with different parameters by clicking Retry. On clicking Retry, you will be presented with the method invoke dialog as described in the Invoke Method sections above.
  Once an object is added to the test bench, hovering over it will bring up the Enhanced Datatip.
  The enhanced datatip allows you to navigate the entire object – all fields, properties, entire parent hierarchy right up to System.Object by just hovering. Apart from navigating the entire object, you can also change/edit the read/write fields & properties.
  The enhanced datatips also give you access to the customized display of objects using the Debugger Visualizers.
  This is useful when you have written a utility function that has especially convoluted algorithm (E.g. generating CRC for a given block of data)… Now once you have finished implementing the algorithm in a GenerateCRC32 function, you would like to perform some unit tests. You then typically invoke this method using OTB as described above.
  Now what happens when you see that the method call result is not what you expected? The first instinct is to place a breakpoint and step through the code right? But wait, don’t F5 yet!
  Instead place a breakpoint at the relevant point inside GenerateCRC32 and then invoke this using OTB. Once you have entered the required parameters and pressed OK in the Invoke Method dialog, OTB asks the debugger to evaluate GenerateCRC32. Note that we are still in the design mode when the debugger starts evaluating GenerateCRC32 under the hood.
  Now when this under–the–hood–execution hits the breakpoint, the debugger enters break mode and you will see that the function evaluation has been suspended at the breakpoint. Now you are *completely* in break mode – you can use the autos/locals windows; do step–in/step–over/step–out; use (quick)watch windows and all other IDE features that you normally use while stepping through. It is as if you had pressed F5/F10/F11 initially and entered directly into GenerateCRC32. Note that for the usual F5/F10/F11 process you have to write a driver code for you utility method, step through the driver code and then finally reach and step through GenerateCRC32. Essentially, you are doing F1/F10/F11 on any arbitrary function without having to write driver code.
  Once you are done stepping through GenerateCRC32 you can simply hit a F5 and the debugger will reenter the design mode (Note: design mode not run mode), wait for the function evaluation to complete, return the method’s return value to OTB. Finally OTB will display the result as described in the Method Call Result section above.
  I hereby dub thee Design–Mode–Debugging! :-)
  One way to look at OTB is that it is an intelligent GUI over the Immediate Window (IW). Whatever you do using OTB you can also do using the IW (albeit you don’t have the features described in the above sections). So if you declare an integer using “int i = 0;” in the IW, the integer “i” will appear in the test bench. Subsequently if you change the value of “i” or even delete “i”, these operations will get reflected on the test bench.
  What’s more, every operation performed by OTB is logged into the command window as statements in the language of the project you are working on. You can save this sequence of statements and later on execute them one by one in the IW to recreate your session.
  But there are certain cases in which you would want to use the IW because OTB doesn’t provide a way out. Remember that I had earlier mentioned earlier that using Create Instance UI you cannot create instances of abstract classes, arrays, delegates, interfaces, enums etc.? Well using IW you can get around most of this limitation. You get instances of arrays, delegates and enums on the test bench by simply executing their constructor statements in the IW. E.g. “string[] stringArray = new string[] { "1", "2" };”. For abstract classes and interfaces you can get their null instances on the test bench by simply executing their declaration statements. E.g. “IAppDomainSetup appDomainSetup;”.
  Now you might ask: Using the IW, can I trick OTB into adding instances of instantiated generic classes? Unfortunately no! An object of any CodeType that OTB doesn’t recognize will not be added to the test bench, although it is possible to create such objects and use them from the IW. What this means that if you evaluate “List<int> intList = new List<int>();”, the object “intList” will be created and you can invoke methods on it from the IW. But “intList” will not be added to the test bench and OTB cannot operate on “intList”.
  An important scenario is when you have created a lot of objects on the test bench and then for some reason you need to make a minor change to the code before you can create the next object or invoke the next method. What happens then?
  Technically, once you have recompiled the code, the new assembly generated and classes in it are completely different from the ones in the previous built even though you may not have made any code changes. Extending this, once you have objects on the test bench and then you make some changes to the code, the objects aren’t really valid. They are from classes that have been discarded. Basically you cannot invoke methods on the new classes/objects using objects from the discarded classes.
  So in the scenario above, once there are changes in the project that require a rebuild, OTB will prevent you from performing the next operation without a rebuild. You can choose to rebuild the project in which case the test bench will be cleared. Alternatively you can continue to inspect and modify the objects on the test bench using the enhanced datatips.
  In case of failures that occur while OTB is performing some operation, OTB will abort the current operation and report a diagnostic message about the failure. These failures include build breaks, unhandled–exceptions and other general failures. In case of unhandled–exceptions the diagnostic message will be the exception’s text message. Once presented with the error, you can take the corrective measures and retry the operation.
  Whew! That pretty much describes what you can do using OTB. Next blog in this series will illustrate some real life use–cases. See you then…
  (To be continued…)
  Hi everyone,
  I have been busy lately for a couple of reasons at least... One of them is the hectic schedule in the Whidbey Beta 2 end game. The other is that I am moving over to a new team – so I am in the process of transitioning out/into my current/next team... Very exciting time, really!
  Meanwhile we have some new stuff for J# users... Recently, Pratap Lakshman (the cool dude, J# Lead PM) has been on MSDN TV with a lot of cool info on J#...
  Please go through his video and do send us your feedback...…
  Hello everyone...
  The entire division has been really really busy over the last few weeks! We have just about begun the final phase of the Visual Studio 2005 Beta 2 release. And personally I haven’t much time for anything else – totally absolutely heads down on bug fixing!
  Well, what better job in the world that to write code, debug and fix bugs? And what better place in the world to work than in Microsoft Corporation?
  Visual J# rocks!!! Visual Studio rocks!!! Microsoft Corporation rocks!!!
  Anyways coming back the topic of this blog, I wanted to let everyone know about some of the coolest articles on Visual J#. Here they are…
  Visual J# language features:
  1. Delegates in J#: Understand what delegates are and how to use them from Visual J#.
  2. Exception handling in J#: How does Visual J# integrate the Java-language exception handling model with the one provided by the CLR.
  3. Properties in J#: Learn how to author and consume .NET properties and indexers from Visual J#.
  Migrating to .NET:
  1. Moving from WFC to the .NET Framework: An overview and comparison of Windows Foundation Classes and .NET Framework class library.
  2. Migrating Java Applets to Microsoft J# Browser Controls: Learn all about J# Browser Controls and how to migrate Java Applets to .NET Framework… (There are 4 sub-articles, be sure to go through them also)
  Problem solving using Visual J#:
  1. Design Concepts using Visual J#: Review design solutions available in Visual J#.
  2. Delegates in Action: Learn how to use Delegates in Visual J# for problem solving
  3. Solving Constraints: This is a cool one – design a system representing an equation with more that one variable.
  These articles are written by Pratap Lakshman. He is the Lead Program Manager in the Visual J# team. And he is a totally cool dude! You can reach him here.
  For more articles stay tuned on this or if you have an RSS reader, subscribe to the RSS feed for Visual J#.
  In my next post, I will be writing on Object Test Bench – my pet feature in Visual Studio 2005 and the one I have been working on for the last year or so…
  See you later…
  Sometime back the following question came up on an internal discussion:
  "How to call method written in x lanuage from C#. In particular, I have several Java-language classes that I don't want to rewrite them in C#. How can I call them from C#. I understand that I can call a C/C++ dll from C# and load jvm within the c/c++ code. But is there anything more efficient?"
  The answer to this question pretty much explains why Visual J# exists. Here is what I replied to the above question:
  Apart from the load-jvm-and-execute option, you do have a few sleeker options:
  1. If you have compiled .class binaries only and you don’t have access to the Java-language sources, you can use JBImp.exe (part of .NET SDK) to convert the .class files to managed assemblies.
  JBImp will convert all compiled code that meets certain conditions.
  Once you have managed assemblies – you can pretty much use it from any managed language – J#, C#, VB, MC++, etc.
  2. If you have access to the J++ project and associated Java-language sources and you want to continue coding in the same language, you should run your sources through the J++ to J# Upgrade Wizard (part the VS IDE). This upgrade wizard will generate an upgrade report that lists all compatibility issues etc. and gives you suggestions/workarounds on how to modify them so that they can be compiled for the .NET platform.
  Once the upgrade wizard is done you will get J# code that can be compiled (with the modifications suggested in the upgrade report) into managed assemblies using the J# complier.
  (Note that if you do not have access to only the Java-language sources and not the J++ project, you may not be able to run J# Upgrade Wizard. Nevertheless you can simply compile the sources and as long as these conditions are met)
  3. If you are keen on moving into .NET completely, C# should be your choice of language.
  In that case you will need to run your sources through the Java Language Conversion Assistant (part of VS IDE).
  The JLCA will basically convert your Java-language sources to C# sources and C# compiler will do the rest for you.
  (Please see the foot note on JLCA)
  Having said that, J# is the solution for Java-language developers on .NET platform.
  The Visual J# tool comes with its compiler, a Java binary importer (JBImp above) and complete java-language support subject to this. Visual J# is also integrated into the VS IDE – you create/manage projects (and migrate J++ projects), use a number RAD tools for a super coding experience, use a rich visual debugger, build deployment solutions, etc.
  For more information please visit the Visual J# home page. There you can get the latest information, articles, documentation, downloads, etc.
  In my next post I will talk about Visual J# 2005 features and which of those I work on.
  Please note:
  1. JLCA is a very powerful tool and is shipped by a sister team of Visual J#, internally called the NetStep Team. TBright is a Program Manager in that team.
  2. Microsoft Visual J# .NET is not a tool for developing applications intended to run on a Java virtual machine. Applications and services built with Visual J# .NET will run only in the .NET Framework; they will not run on any Java virtual machine. Visual J# .NET has been independently developed by Microsoft. It is neither endorsed nor approved by Sun Microsystems, Inc.