Rick Minerich's Development Wonderland : VB.NET

F# Discoveries This Week 11/22/2009

RickM — Sun, 22 Nov 2009 23:49:52 GMT

Over this past week at PDC I was lucky enough to see some fantastic sessions and spend time with members of the F# and greater Visual Studio language teams. Naturally, these experiences have left me both floored and swimming in new ideas. This edition of Discoveries This Week includes both the very best of what I saw at PDC 2009 and the most outstanding things I’ve glimpsed going on in the F# community. Please do enjoy.

Reflection on the PDC Keynotes

For the most information in the shortest amount of time I suggest watching the day one and day two PDC keynotes. They are both jam packed with exciting announcements and demos. While at PDC I wrote about my experience watching these here (day one) and here (day two).

Microsoft Perspectives on the Future of Programming

Come hear from several of the Microsoft senior technical leaders about the future of programming, programming languages, and tools.

If you watch just one PDC session let this be it.

With Butler Lampson, Erik Meijer, Don Box, Jeffrey Snover, Herb Sutter, and Burton Smith, Microsoft’s best gathered to debate the future of programming in a twitter driven panel at PDC. I was happy to be able to contribute with a question on type systems which erupted into quite a disagreement. I will be writing about this session at length, and reflecting on my past thoughts about this topic, in the near future.

Luke Hoban’s F# for Parallel and Asynchronous Programming

F#, a functional and object-oriented language for Microsoft .NET, adds many tools to make parallel and asynchronous programming both fun and easy. Come hear the core concepts of the F# language, and see how ideas like immutability, functional design, async workflows, agents, and more can be used to meet the challenges of today’s real-world applications.

By combining small, easily understood, ideas Luke constructs F#’s big picture in the most engaging way I’ve seen to date. This is now my go to talk for people who are interested in, but new to, the F# programming language.

Jomo Fisher’s F# Scripting, .NET 4.0 and Mixed-mode assemblies

One of the recent problems we’ve seen is that, because of the support for side-by-side runtimes, .NET 4.0 has changed the way that it binds to older mixed-mode assemblies. These assemblies are, for example, those that are compiled from C++\CLI. Currently available DirectX assemblies are mixed mode.

This clever approach to switching the F# REPL to 2.0 binding mode is particularly handy to know.

Matthew Moloney’s Collaborative Development Using F# Interactive

This is a proof of concept of an interactive collaborative development environment I built using F# Interactive. The aim here is to explore different ideas for further development, not so much as to present an alternative to Visual Studio.

I couldn’t pass this very cool idea up. I can’t help but think about extending this to full feldged explorative programming community websites.

Bart Czernicki’s Silverlight 3 and F# Support in Visual Studio 2010

The goal of this blog post is to make you aware of F# support in Silverlight in Visual Studio 2010. In addition, this blog post shows an example why F# is going to be very important for Silverlight architects and developers. Note: This is NOT an intro to F#.

A great post. I am always interested in seeing concrete examples of F# adding value to existing technologies and platforms. I have a sneaking suspicion that there are very few places where it won’t.

.NET 2.0 ActiveX Control Gotchas (Safe for Scripting and Hooking into Events)

RickM — Wed, 03 Jun 2009 17:41:00 GMT

I’ve recently been building an ActiveX Control in .NET 2.0 and thought I would share some of the problems I’ve run into, as well as their solutions. I hope that in reading this you can avoid a few of the timesinks I fell into.

Safe for Scripting

By default, ActiveX controls are not marked as safe for scripting. This means that Internet Explorer will refuse to run a control given it’s default settings, even for sites in it’s Trusted security zone. Thankfully, this is an easy problem to correct.

The Wrong Way

It’s possible to hide this issue on the client machine by setting “Initialize and script ActiveX controls not marked safe for scripting.” to true or prompt. This, of course, is not an acceptable solution as it will require all clients to do the same and in so doing potentially open them to malicious controls.

The Correct Solution

There are two ways to mark an ActiveX control as safe for scripting. The first, and easiest in the context of .NET, is to implement the IObjectSafety interface. The only caveat to this method is that it requires that you can modify the ActiveX control’s source code.

The second, more complex option, is to use COM Component Categories Manager. While not requiring source changes and recompilation, this method requires a rather large amount of registry editing. As I did not take this approach, I won’t delve into it further. Additional .NET implementation information is available in this CodeProject article.

IObjectSafety

Implementation requires first importing the IObjectSafety interface. This is a simply a matter of declaring a interface with the ComImport attribute.

While in most cases it is extremely important to ensure the Guid tags on your interface declarations are unique, in this case it equally important not to change it. This is because the GUID attribute here is that of the IObjectSafety interface. To put it plainly, changing the Guid in the following example will cause it to not work.

  1: [Flags]
  2: public enum IObjectSafetyOpts : int //DWORD
  3: {
  4:     // Object is safe for untrusted callers.
  5:     INTERFACESAFE_FOR_UNTRUSTED_CALLER  = 0x00000001,
  6:     // Object is safe for untrusted data.
  7:     INTERFACESAFE_FOR_UNTRUSTED_DATA    = 0x00000002,
  8:     // Object uses IDispatchEx.
  9:     INTERFACE_USES_DISPEX               = 0x00000004,
 10:     // Object uses IInternetHostSecurityManager.
 11:     INTERFACE_USES_SECURITY_MANAGER     = 0x00000008
 12: }
 13: 
 14: public enum IObjectSafetyRetVals : uint //HRESULT
 15: {
 16:     //The object is safe for loading.
 17:     S_OK            = 0x0,
 18:     //The riid parameter specifies an interface that is unknown to the object.
 19:     E_NOINTERFACE   = 0x80000004
 20: }
 21: 
 22: [ComImport()]
 23: //This GUID is that of IObjectSafety. Do not replace!
 24: [Guid("CB5BDC81-93C1-11CF-8F20-00805F2CD064")] 
 25: [InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
 26: public interface IObjectSafety
 27: {
 28:     [PreserveSig()]
 29:     IObjectSafetyRetVals GetInterfaceSafetyOptions(ref Guid riid, out IObjectSafetyOpts supportedOpts, out IObjectSafetyOpts enabledOpts);
 30:     [PreserveSig()]
 31:     IObjectSafetyRetVals SetInterfaceSafetyOptions(ref Guid riid, IObjectSafetyOpts optsMask, IObjectSafetyOpts enabledOpts);
 32: }
 33:

You then need only implement this interface in your ActiveX control as follows.

  1: ...
  2: public partial class ExampleControl : IObjectSafety
  3: {
  4:     public IObjectSafetyRetVals GetInterfaceSafetyOptions(ref Guid riid, out IObjectSafetyOpts supportedOpts, out IObjectSafetyOpts enabledOpts)
  5:     {
  6:         supportedOpts = IObjectSafetyOpts.INTERFACESAFE_FOR_UNTRUSTED_CALLER | IObjectSafetyOpts.INTERFACESAFE_FOR_UNTRUSTED_DATA;
  7:         enabledOpts = IObjectSafetyOpts.INTERFACESAFE_FOR_UNTRUSTED_CALLER | IObjectSafetyOpts.INTERFACESAFE_FOR_UNTRUSTED_DATA;
  8:         return IObjectSafetyRetVals.S_OK;
  9:     }
 10: 
 11:     public IObjectSafetyRetVals SetInterfaceSafetyOptions(ref Guid riid, IObjectSafetyOpts optsMask, IObjectSafetyOpts enabledOpts)
 12:     {
 13:         return IObjectSafetyRetVals.S_OK;
 14:     }
 15:     ...
 16: }
 17:

With the IObjectSafety interface implemented to return INTERFACESAFE_FOR_UNTRUSTED_CALLER and INTERFACESAFE_FOR_UNTRUSTED_DATA, your object is considered scripting safe for use by Internet Explorer. Your control should no longer require any non-default ActiveX related settings to run.

INTERFACE_USES_DISPEX and INTERFACE_USES_SECURITY_MANAGER are mainly used for scripting engines and can be safely ignored.

Hooking into Events

Working on my current project, I spent a not insignificant amount of time working to make events fire correctly. I started with a simple implementation, similar to what is discussed in this article.

  1: <object id="ActiveXExample" name="ActiveXExample" 
  2:   classid="clsid:21192EDE-868C-4b94-9D20-B822C42EA9D2" 
  3:   codebase="ActiveX.cab#version=1,0,0,0" VIEWASTEXT>
  4: </object>

  1: [Guid("C07F993D-242D-4c1e-AF1B-B77CAE5FD088")]
  2: [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
  3: public interface IExposedComEvents
  4: {
  5:     [DispIdAttribute(0x60020001)]
  6:     void ExampleEvent(string text);
  7: }
  8: 
  9: [Guid("21192EDE-868C-4b94-9D20-B822C42EA9D2")]
 10: [ClassInterface(ClassInterfaceType.None),
 11:  ComSourceInterfaces(typeof(IExposedComEvents))]
 12: [ComVisible(true)]
 13: public partial class ActiveXExample
 14: {
 15:     public event ExampleEventHandler ExampleEvent;
 16:     ...
 17: }
 18:

  1: <script language="javascript">
  2: function ActiveXExample::ExampleEvent(text)
  3:     try {
  4:         elem = document.getElementById("status");
  5:         elem.innerHTML = text;
  6:     } catch(exception) {
  7:         alert("Exception Thrown in Event: " + exception);
  8:     }
  9: </script>

However, I found that my javascript events were not being registered. After some fiddling, I discovered that I was able to capture the event by instead using the “for-object event” script tag.

  1: <script for="ActiveXExample" event="ExampleEvent(text)">
  2: try {
  3:     elem = document.getElementById("status");
  4:     elem.innerHTML = text;
  5: } catch(exception) {
  6:     alert("Exception Thrown in Event: " + exception);
  7: }
  8: </script>
  9:

I’m still not quite sure why the Object::Event syntax didn’t work, as it is shown often in ActiveX sample code. Still, if you find you are having issues getting events to fire correctly, this alternate syntax may be worth trying.

Additional Resources

MSDN: Safe Initialization and Scripting for ActiveX Controls

Eric Lippert's Fantastic Eight Part Series: Script and IE Security
One, Two, Three, Four, Five, Six, Seven and Eight

How to determine which language(s) were used to build a .NET assembly

RickM — Thu, 26 Feb 2009 11:00:00 GMT

While in most cases there is no explicit information in an assembly as to which languages it was compiled from, it is possible to make an educated guess as to which languages were used. This is due to the fact that each different .NET compiler leaves it’s own unique type of fingerprint. In this article I discuss both my methodology for finding these fingerprints and which were unique to each language I used.

Methodology

For each language I made a new class library project. I then reflected and compared each assembly to determine which unique characteristics it had. It turned out that, at least for C#, F#, VB and C++, each was uniquely identifiable by the existence, or lack thereof, of certain features.

So to break it down a bit.

In each project I added one class and one public method in each of those classes:

  1: public class CSharpClass
  2: {
  3:     public void LocalMethod() {}
  4: }

After compiling each of these projects into it’s own assembly, I referenced them from another testing project. To grab a set of features for each language, I used the following three reflection calls:

Assembly.GetTypes()
Assembly.GetCustomAttirbutes()
Module.GetFields( BindingFlags.NonPublic | BindingFlags.Static )

Then, with a simple program, I found which of these features were unique for each language. This set of unique features ultimately represents a map of the imprint each compiler leaves.

F#

A compiled F# library will only have one attribute by default:

Microsoft.FSharp.Core.FSharpInterfaceDataVersionAttribute

This made it the easiest to differentiate of all the languages I tested. Even more interesting, this attribute contains three fields which specify the specific version of the F# compiler used to generate the assembly:

Major    1    int
Minor    9    int
Release    6    int

I’m always impressed with how the F# team consistently goes above and beyond when it comes to the small details.

Visual Basic

The Visual Basic assembly I generated was also easily identifiable via extra types which were automatically added:

My.MyApplication
My.MyComputer
My.MyProject
My.MyProject+MyWebServices
My.MyProject+ThreadSafeObjectProvider`1
My.Resources.Resource
My.MySettings
My.MySettingsProperty

As you can see from this list, the existence of these types in the “My” namespace is a fairly safe indicator that the Visual Basic language was used.

C++ CLI / Managed C++

C++/CLI and Managed C++ are considered to be the same language with slightly different syntax as they share the same compiler. However, there are four different compilation modes for C++ and each has somewhat different results.

/CLR – Common Language Runtime Support
/CLR:pure – Pure Common Language Runtime Support
/CLR:safe – Safe Common Language Runtime Support
/CLR:OldSyntax – Managed C++ Syntax

The /CLR, /CLR:pure and /CLR:OldSyntax settings provide easy to classify assemblies, as they all inject an enormous number of types (70+) into the assembly. I verified that contained two types from the vc_attributes namespace:

vc_attributes.YesNoMaybe
vc_attributes.AccessType

However, /CLR:Safe is much different in that it injects no types and adds no assembly attributes by default. The generated assembly was almost completely clean. I was forced to use Reflector to determine how to differentiate this from C#.

C#

C# was one the most difficult to identify assembly type. This is due to the fact that it has no unique types and only one unique attribute:

System.Reflection.AssemblyConfigurationAttribute

Unfortunately, this attribute is defined in the AssemblyInfo.cs file and so we can’t depend on it. Up to this point it was only necessary to use two reflection calls:

Assembly.GetTypes()
Assembly.GetCustomAttirbutes()

I was hoping to keep things very simple. However, to differentance these two languages it’s necessary to go a bit further. It turns out that C++ always injects an module level field into the assembly while C# does not. And so by using:

Module.GetFields(BindingFlags.NonPublic | BindingFlags.Static)

We can check for the existence of this kind of field and so differentiate these two types.

After some investigation with reflector, I was able to find one particular feature unique to C#. Unfortunately, it requires disassembling functions and looking at the resulting IL. It seems as though a function definition never has a .maxstack of less than 8. In all other languages I observed .maxstack had been set to values as low as 0 when defined in an empty function.

However, as I am only currently concerned with these four languages, my testing on this matter has been very shallow and so pleae take it with a grain of salt.

Conclusion

I admit that my sample Assembly set was very small and my feature set very large. However, while this type of classification may not be robust enough to be applicable to a system which depended on these results being absolutely true, I’ve shown that it is in fact entirely possible to make reasonably confident guesses as to the language used to generate a .NET assembly while using only simple reflection. It would be interesting to see how well this holds for obfuscated assemblies as well as other “bare minimum” compilations generated via different combinations of compiler settings.

The next obvious step would be to extend what I have already written into a full Bayesian classifier. Would be much better than a hardcoded hierarchy which would be fragile and possibly completely and repeatedly incorrect for some cases. Another big advantage of using machine learning here, is that it would be easy to add new features and classification categories.

One of these languages is not like the others - Part 1 - Enforcement of Abstract Implementation

RickM — Tue, 10 Feb 2009 15:47:00 GMT

This is the first in a series of posts on the topic of interaction between different .NET languages. I will cover all of the major Microsoft languages: C#, Visual Basic, F# and C++/CLI.

In this first post in the series I will build a four language project in Visual Studio 2008 and begin to explore inter-language inheritance. One of the languages behaves in a significantly different way when compared with the others, can you guess which one it is?

Enforcement of Abstract Implementation

First things first, let’s define our abstract base class. C# is considered the standard language for library architecting and so it is what we will be using.

  1: public abstract class CSharpBaseClass
  2: {
  3:   public abstract void PublicAbstractMethod();      
  4:   public abstract void PublicAbstractMethod(int inint);
  5:   protected abstract void ProtectedAbstractMethod();
  6:   protected abstract void ProtectedAbstractMethod(int inint);
  7: }

In each of our child projects we will be inheriting from this class. Let’s start with C#.

  1: public class CSharpChildClass : CSharpBaseClass
  2: {
  3: }

Now anyone with even a bit of experience in the C# language knows that this won’t compile. For each of the abstract methods in the base class the inheriting class is expected to provide an implementation.

… error CS0534: 'CSharpChild.CSharpChildClass' does not implement inherited abstract member …

This is similarly true for Visual Basic.

  1: Public Class VBChildClass

  2:   Inherits CSharpBase.CSharpBaseClass

  3: End Class

… error BC30610: Class 'VBChildClass' must either be declared 'MustInherit' or override the following inherited 'MustOverride' member(s):

F# shares this behavior as well.

  1: type FSharpChildClass() =
  2:   inherit CSharpBase.CSharpBaseClass()

… error FS0191: No implementation was given for 'CSharpBaseClass.PublicAbstractMethod() : unit'.

Kudos to the F# compiler designers for the verbose compile time errors.

error FS0054: This type is 'abstract' since some abstract members have not been given an implementation. If this is intentional then add the '[<AbstractClass>]' attribute to your type.

However, C++/CLI does not. It’s perfectly acceptable to inherit from an abstract class and provide no implementation for it’s abstract members.

  1: public ref class CppChildClass : public CSharpBaseClass
  2: {
  3: };

While a warning is issued, it seems insufficient for what has just taken place:

… warning C4570: 'CppChild::CppChildClass' : is not explicitly declared as abstract but has abstract functions

The result is that the class in question is defaulted to abstract. If someone where to attempt to instantiate it downstream, it would cause a compiler error:

  1: CppChildClass cpp = new CppChildClass();
  2: cpp.LocalMethod();

error CS0144: Cannot create an instance of the abstract class or interface 'ManagedCppChild.ManagedCppChildClass'

This is bad because, if you were an API developer and so did not consume all of your objects, it would be possible to ship a version of your product with abstract suddenly toggled on for one or more of your classes. All it would take would be for a developer to add a new inherited class or member to an existing abstract base class without writing a corresponding test for every abstract member or inheriting class.

Conclusion

So, what can we learn from this? It seem that when using C++/CLI (or managed C++) it is not sufficient to depend on abstract classes to enforce that members are implemented. Testing must also be strictly enforced.

Changing Your Garbage Collector Settings on the Fly (.NET Memory Management: Part 5)

RickM — Wed, 20 Aug 2008 20:39:00 GMT

It has come to my attention via a recent DZone article that .NET 3.5 and 2.0 SP1 jointly included a new feature which lets you manipulate the way your garbage collector acts programmatically. This can be done through changing the value of a new property of the System.Runtime.GCSettings class named LatencyMode. In this article I will walk you through this new property and the different effects of each of it's possible settings.

Other Articles in This Series

Part 1 – Basic Housekeeping
Part 2 – Improving Performance Through Stack Allocation
Part 3 – Increasing the Size of your Stack
Part 4 – Choosing the Right Garbage Collector Settings
Part 5 – Changing Your Garbage Collector Settings on the Fly

LatencyMode

The new LatencyMode property accepts three different enumerated values. The first two of which are Batch and Interactive which correspond to turning <gcConcurrent> on and off inside of your application configuration. However, the effects of the third value, which is named LowLatency, were previously unavailable by any means. By setting this the LatencyMode to LowLatency you can now put the Garbage Collector in an ultra-conservative mode which will insure the application will be interrupted as infrequently as possible.

There are a couple of things you should take note of before changing your Garbage Collector's LatencyMode:

LatencyMode settings are process-wide and so all of the threads in your application will be effected.
Changing LatencyMode will have no effect if your application has <gcServer> mode set in its configuration file.

Now, let’s explore each of the possible values of LatencyMode in detail:

Batch

When it’s useful:
It’s useful in applications without a UI and in Server Based Software. It may also be useful to switch your garbage collector into Batch latency mode if your application has a data crunching mode which occurs after a user interface.

What it does:
This is the most intrusive setting. Garbage Collection is done non-concurrently in one big batch call. Your program will be suspended while garbage collection takes place.

Defaults:
This is the default value when <gcConcurrent> is disabled.

Notes:
Even though this will be the enumeration which will be set if <gcServer> is enabled, the garbage collector will act as described in my previous article. In fact, if you have your application defined to be in <gcServer> mode the LatencyMode property cannot be changed from its default of “Batch”.

Interactive

When it’s useful:
It’s the best mode for most any UI-based application.

What it does:
This is the most balanced setting. Garbage Collection happens concurrently with your application. Most of the work is done in a separate thread and although your application will be suspended it will not happen very often and for only very short periods of time.

Defaults:
This is the default value for garbage collection on workstations. If <gcConcurrent> is left at its default value, this is the type of garbage collection that will occur.

LowLatency

When it’s useful:
It’s useful for time sensitive applications such as 3d rendering or data acquisition.

What it does:
This is the least intrusive mode the Garbage Collector can be set to. As in Interactive, garbage collections happen concurrently with your application. However, collection of older objects will only happen when memory pressure becomes high. Collection of generation 2 objects is kept to a bare minimum.

Defaults:
This is never the default setting.

Notes:
LowLatency mode was designed for short time use only during time-critical sections of your application. Leaving an application in LowLatency mode for an extended period of time will cause unused objects accumulate. Before using low latency mode, you should take a look at the guidelines laid out at the bottom of the MSDN Latency Modes page.

References
MSDN Visual Studio 2008 Developer Center – Latency Modes
MSDN .NET Framework Developer Center – GCLatencyMode Enumeration
DZone - Low-Latency GC in .NET 3.5

Choosing the Right Garbage Collector Settings for Your Application (.NET Memory Management: Part 4)

RickM — Wed, 14 May 2008 18:11:00 GMT

Tuning the garbage collector to the specific context of the particular application can significantly improve the performance of both non-threaded and multi-threaded applications. In this post I discuss the gcConcurrent and gcServer settings which allow...(read more)

Custom Serializing Objects for Use in a Debugger Visualizer

RickM — Wed, 07 May 2008 19:02:00 GMT

I have a new CodeProject article up which details how to make a Debugger Visualizer in the case where you need to custom serialize the object. The actual classes I build in the tutorial are only useful with our DotImage project line. However, the process...(read more)

Basic Memory Housekeeping (.NET Memory Management: Part 1)

RickM — Thu, 03 Apr 2008 21:25:00 GMT

This is the first in a series of posts I will be writing about managing memory in .NET. Before I move on to more complex techniques, I thought it would be good to cover the basics. Articles in This Series Part 1 - Basic Housekeeping Part 2 - Improving...(read more)

Counting Processors in .NET: The Pros and Cons of Five Different Methods

RickM — Tue, 01 Apr 2008 18:54:00 GMT

There are a great number of different ways to count the number of processors available to the .NET developer. In this post I will go over some of the more common methods and their pros and cons. The Envirionment.ProcessorCount Way Code: Environment .ProcessorCount;...(read more)