Category: .NET

Posted on

Double Trouble with COM Interop

I have been calling FoxPro code from C# via COM Interop (using DotNet2Fox) for several years, but I ran across an interesting issue last week. I have some FoxPro code that performs calculations and returns the results to .NET. I expected one of those values to be zero, but according to C#, it was -3.5527136788005e-15. Huh? After repeated tests, I got the same result.

I was assigning the FoxPro results to C# variables of type “decimal”. The C# compiler had already informed me that FoxPro was returning values with type “double” over COM. I have heard about the tension between binary and floating point math in computers before, but in practice, I have never run into an issue. I initially thought that the double-to-decimal conversion in C# was exposing this tension. As a test, I changed my C# variables to type double, but the problem persisted. I stepped through my code in FoxPro, and according to the debugger, the value was indeed zero. What the heck was going on?

I came up with a simpler calculation to reproduce the issue: 1.23 + 4.56. The result should be 5.79, right? Enter ? 1.23 + 4.56 in the FoxPro command window, and that’s what you’ll get. However, run the code below in C# and the result will be 5.790000000000001. 

        dynamic vfp = Activator.CreateInstance(Type.GetTypeFromProgID("VisualFoxPro.Application", true));
        var result = vfp.Eval("1.23 + 4.56");
        vfp.Quit();
        return result;

Had I run across some glitch with COM interop? I needed to be certain that calculations done in FoxPro would come over to C# accurately. This was disconcerting.

Upon further thought… someone would have surely caught an issue like this with general COM interop, right? Maybe this was more on the FoxPro side. Then, I remembered a blog entry Christof wrote years ago on Significant digits in Visual FoxPro that mentions some oddities with 15-digit floating point calculations in VFP. Hmmmm… 15 digits. That’s the same precision of double types in C#. And look how many digits are after the decimal place in 5.790000000000001. So, I tried another test in the FoxPro command window:

SET DECIMALS TO 15
? 1.25 + 4.56

There it is! Now, FoxPro shows 5.790000000000001! Clearly, this is either some kind of binary-to-floating-point issue or something to do with that 15th digit, but SET DECIMALS masks that most of the time. SET DECIMALS is a mysterious command. It specifies the number of decimal places that will be displayed from calculations. It apparently also affects comparisons: ? 1.25 + 4.56 = 5.79 returns .T. when SET DECIMALS TO 2. But SET DECIMALS TO 15 and the same expression returns .F. Weird! SET DECIMALS appears to have no effect on calculated values returned over COM interop and always returns the full 15-digit precision of a double.

So, that explains why I had the issue when using COM interop. How do we fix it? Simple… round the calculated result to the desired number of decimals in FoxPro before returning the result, or in C# after the result is returned from FoxPro. In fact, I was able to resolve by rounding down to 14 digits (eliminating the troublesome 15th digit), but I can’t guarantee that would always work. By the way…if you want C# rounding to have the same behavior as FoxPro rounding, specify MidpointRounding.AwayFromZero:

    public static double FixDouble(double number, int roundDecimals = 14)
    {
        return Math.Round(number, roundDecimals, MidpointRounding.AwayFromZero);
    }
Posted on

DotNet2Fox is now part of VFPX!

I’m happy to announce that DotNet2Fox has been accepted as part of the VFPX project.  “What is DotNet2Fox?”, you say?  Good question!  DotNet2Fox was first presented and released at Virtual Fox Fest 2021 (October), and I somehow failed to mention that here on my blog!  That is being rectified right now…

DotNet2Fox is an open-source library that simplifies calling Visual FoxPro code from .NET desktop and web applications. Have you tried your hand at COM interop only to be met with limitation after limitation? Did you find that exposing your existing FoxPro code over COM would require a major refactoring effort? DotNet2Fox provides a simplified interface for calling into existing real-world FoxPro code, and without all those limitations.

Over the past several years, I have been working to surface features from my desktop applications and make them available on the web via ASP.NET.  I found that the classic approach to COM interop recommended by Microsoft a couple of decades ago did not fit my needs. Over time, a library emerged to meet those needs: DotNet2Fox.

Geek Gatherings has graciously made recordings of Virtual Fox Fest sessions available to the entire FoxPro community on YouTube.

You can also get the whitepaper (documentation) and examples at the GitHub Wiki. Yes, full source code is on GitHub as well.  If you need help with DotNet2Fox, please start a Discussion or report an Issue. We’ll even accept Pull Requests.  I look forward to working with more folks  on this project.

Posted on

COM Interop with .NET Core 3.x and .NET 5.0

I previously wrote about COM Interop with .NET Core 1.0 and .NET Core 2.0. I haven’t had a chance to write it about it since, so this discusses both .NET Core 3.x and .NET 5.0.  If it wasn’t obvious from the previous articles, this is about calling COM components from .NET.  I believe work was done using COM interop in the other direction (calling .NET from COM components), but it is not discussed here. If you need to call .NET from Visual FoxPro, wwDotNetBridge is much simpler than standard COM Interop and highly recommended.

.NET Core 3.x

.NET Core 3.0 was a big release.  Unlike ASP.NET Core 2.0, ASP.NET Core 3.0 removed the option to run on .NET Full Framework 4.x.  It only runs on .NET Core, meaning you can no longer fall back to 4.x for COM Interop support.  WinForms and WPF desktop applications were also brought into the Core fold for the first time, and some of those apps might rely on COM Interop.

Some progress was made in 3.0, but the overall COM Interop story is the same as .NET Core 2.0.  That is, COM Interop works, but late binding using the C# dynamic keyword still doesn’t function.

dynamic excel = Activator.CreateInstance(Type.GetTypeFromProgID("Excel.Application", true));
excel.Visible = true;
Console.WriteLine("Press Enter to close Excel.");
Console.ReadLine();
excel.Quit();

As with .NET Core 2.0, the above code will function in .NET Framework 4.x, but in .NET Core 3.x, an exception occurs:

‘System.__ComObject’ does not contain a definition for ‘Visible’

Microsoft had planned to bring full support for the dynamic keyword to .NET Core 3.0, but the job proved to be too large, so it was deferred. However, there are a couple of improvements.

In .NET Core 2.0, you had to jump through hoops to create an interop assembly for COM components.  In .NET 3.x projects with Visual Studio 2019, you can simply right-click on the project and select “Add COM Reference”.

In addition, some folks put together a workaround using a DynamicObject wrapper to access properties/methods on COM objects using the dynamic keyword, so you don’t have to use ugly reflection calls.  This may not work in every scenario, but you may find it meets your needs on .NET Core 3.x.

.NET 5.0

.NET 5.0 was just launched at .NET Conf on November 10, 2020. It represents the reunification of .NET Core and .NET Full Framework, hence the dropping of “Core” in the product name.  .NET 4.x remains a part of Windows and will continue to be supported indefinitely.  Some things are not coming over to .NET 5, such as Web Forms, WCF, and WWF… at least not by Microsoft. There are open-source projects to port WCF and WWF.  But what about COM Interop?  In my testing, it just works.  Indeed, Microsoft finished the work to support using the dynamic keyword with COM objects.  There’s not much more to say than that.  If incomplete COM Interop support has been keeping you on .NET Full Framework 4.x, now may be the time to take a look at .NET 5.0.

Posted on

COM Interop with .NET Core 2.0

We previously discussed that COM Interop does not function in .NET Core 1.0.  What about .NET Core 2.0?  The answer is YES… with limitations.

The first and most obvious is that COM Interop only works with Windows, not other platforms.

The second limitation is that the .NET Core implementation does not include IDispatch, which means that late binding is not supported.  Almost 10 years ago, Microsoft introduced the dynamic keyword in C# 4.0, which made late binding with COM and other platforms much easier.

dynamic excel = Activator.CreateInstance(Type.GetTypeFromProgID("Excel.Application", true));
excel.Visible = true;
Console.WriteLine("Press Enter to close Excel.");
Console.ReadLine();
excel.Quit();

The above code will function in .NET Framework, but in .NET Core 2.0, an exception occurs:

‘System.__ComObject’ does not contain a definition for ‘Visible’

If you look in Task Manager, you’ll see that Excel.exe has indeed started, but the object members cannot be access directly without IDispatch.  To work around this, you can use interop techniques that pre-date the dynamic keyword.

Interop assemblies are wrappers that enable .NET Core to interact with COM objects using early binding.  Microsoft provides interop assemblies for Office automation on NuGet and elsewhere.  Once the assemblies are installed, this code will work:

using Excel = Microsoft.Office.Interop.Excel;
...
var excel = new Excel.Application();
excel.Visible = true;
Console.WriteLine("Press Enter to close Excel.");
Console.ReadLine();
excel.Quit();

Aside: For web applications, Office automation is not recommended.  Check out the Open XML SDK.

What about your own COM objects? .NET Core projects do not provide a means to reference them directly.  However, you can create a .NET Framework 4.x project and add a reference to the COM object.  This will create an Interop.MyCOMObject.dll assembly in the obj/Debug folder, which you can then reference directly in the .NET Core project.

A COM object may return other objects that are not part of the type library, and early binding is not an option. This happens often in my Visual FoxPro interop code. You can use reflection to access the object members.

object excel = Activator.CreateInstance(Type.GetTypeFromProgID("Excel.Application", true));
excel.GetType().InvokeMember("Visible",BindingFlags.SetProperty, Type.DefaultBinder, excel, new object[] { true });
Console.WriteLine("Press Enter to close Excel.");
Console.ReadLine();
excel.GetType().InvokeMember("Quit", BindingFlags.InvokeMethod, null, excel, null);

The dynamic keyword makes for more natural code, but you can make reflection less cumbersome than above with your own wrapper methods.

For the adventurous, the Powershell team has created their own implementation of IDispatch. I don’t know how reusable this implementation is, but it may be worth a look.

If you’re using in-process (DLL) COM servers, be aware of 32-bit vs 64-bit issues. For web  applications, take a look a Rick Strahl’s post on STA components. I don’t know if these techniques are available in .NET Core.  In my experience, these issues do not apply with out-of-process (EXE) COM servers, but your mileage may vary.

Lastly, keep in mind that ASP.NET Core 2.0 continues to run on .NET Framework 4.x, in addition to .NET Core.  If you’re already restricted to Windows, there aren’t many reasons to prefer .NET Core over the full framework (yet), so it remains the best option for COM Interop.  That said, it’s good to know these possibilities exist with .NET Core.

Microsoft has been choosy about what they bring over to .NET Core.  Over time, they have been finding their way towards more parity with .NET Framework. It was recently announced that WinForms/WPF will be coming to .NET Core 3.0. They may find that a lot of existing code relies on late binding.  I would not be surprised if IDispatch makes a comeback.

Posted on

COM Interop with .NET Core

Logo_DotNet

UPDATE: COM Interop with .NET Core 2.0

The short story is that COM interop does not function in .NET Core 1.0. .NET Core is Microsoft’s open-source, cross-platform implementation of the core libraries in the .NET Framework.  With its cross-platform focus, the exclusion of COM interop is intentional.

ASP.NET Core is Microsoft’s open-source web framework that sits on top of the base .NET framework.  If you require COM interop and want to take advantage of new features in ASP.NET Core 1.0, you are in luck. Scott Hanselman reminds us that ASP.NET Core runs not only on .NET Core, but also on the full .NET Framework 4.6.

Here is some typical code for instantiating a COM object in C#:

dynamic myObject = Activator.CreateInstance(Type.GetTypeFromProgID("My.COMObject", true));

If you try to compile this code with .NET Core 1.0, it simply won’t work because Type.GetTypeFromProgID() is not available in the API.

That describes the current situation, but what about the future?  A while back, there was actually talk about bringing pieces of COM to Mac and Linux.  I think those plans have been scrapped or would only have limited use.

.NET Standard is an effort to bring a minimum common API set to all .NET platforms, present (Full Framework 4.6, .NET Core, Xamarin, Mono) and future.  .NET Standard 2.0 will be implemented in .NET Core 1.1, and it brings in a lot of missing APIs from the full framework. (UPDATE: .NET Core 1.1 has been released since this was written. It includes many new APIs, but not full support for .NET Standard 2.0. That will show up in a future release of .NET Core.)   It should make porting existing code to .NET Core much easier.  One of the APIs slated for 2.0 (as of this writing) is Type.GetTypeFromProgID().  That means that COM interop will work on .NET Core 1.1, right? Wrong. Calling this method will throw a “Not Implemented” or “Platform Not Supported” error.  As I was told by a .NET Foundation member:

There is often incorrect assumption made that “included in .NET Standard” == “works in .NET Core”. There are going to be some APIs that will throw PlaformNotSupportedException on .NET Core, also this set be different between Windows and Unix.

That’s a bit counter-intuitive to me. First of all, it seems like .NET Core should be the “reference implementation” of .NET Standard.  Beyond that, the availability of APIs on unsupported platforms may lead a developer to believe an API is fully functional when it is not. To solve that issue, tooling is coming that will identify APIs that are not supported on certain platforms/runtimes (hopefully before a developer has gone through a porting effort). Also, keep in mind that a least-common-denominator approach has already been tried with Portable Class Libraries, and the .NET team is going for something better. The .NET Standard team is currently accepting feedback on GitHub, so feel free to post your thoughts and questions.

Looking beyond .NET Standard 2.0 and .NET Core 1.1, several COM/native interop pieces have already been segregated for a possible future extension. Also, the source code for the underlying functionality is readily available.  I think it is only a matter of time before COM interop will be available for use with .NET Core.

References:

Posted on

Thoughts on Metro and the Windows Runtime

Like many developers, I spent much of last week and the weekend watching the Microsoft BUILD conference and learning about Windows 8, the new Metro UI, and the Windows Runtime (WinRT).  My first impression of the Metro interface was that it is compelling and I like it.  That has faded a bit as I get into the details of what you can and cannot do with the new architecture.  There is a lot to like about the Metro user and developer experiences, all of which you can learn about at Microsoft and the blogosphere.  As a developer, I’m thinking along the lines of how I can use the new technology while preserving my investment in existing code and skills.  Restrictions built into Metro (by design) have a direct impact on that.  While highlighting all the cool new stuff, Microsoft has glossed over the restrictions a bit, so this post looks at things from that point of view.  First of all, I should say that this is a developer preview, Microsoft is looking for feedback from developers on their design decisions, and some of those decisions may change before release.

The more I learn about Metro/WinRT, the more I realize it is “Windows” in name only.  To start, there are no windows in Metro!  Everything is full screen.  While there are some things shared under the hood (like the Windows Kernel and file system), for the most part, Metro is separate and isolated from the Windows “desktop”.  Metro competes directly with Apple iOS and Google Android in the tablet space, while also being available to PCs. That much is obvious, but being bundled in Windows, you might think you also get access to all the goodness in the Win32 and .NET APIs.  That is not the case.  This really is two operating systems in one box.

So, why not just sell Metro separately as a new OS?  Microsoft already tried that. It’s called Windows Phone 7, and nobody’s buying.  Even Windows Vista had 400 million users, so bundling Metro with Windows ensures there is a viable market for apps.  Besides, we developers would freak out if Microsoft dropped Windows for something entirely new.  Putting Metro in Windows is good all around.

A key point to make is that Metro is client-side technology only.  In spite of support for HTML, these are desktop apps.  The HTML is not served up by a server, but rather is compiled into the Metro app.  Being client-side technology, there are a lot of things Metro doesn’t do.  Microsoft expects your business logic and database access to be done on the server and exposed as a service that Metro apps can consume.  Of course, they would be happy to host this service for you in Azure, but that is not a requirement.

How about the Windows Runtime?  What exactly is it?  It could have just as easily been called the Metro Runtime, because it exists for the sole purpose of servicing Metro apps.  Under the covers, WinRT components are written in native C++ (take that Dev Div!), and interfaces are exposed using COM and metadata.  This does not mean that COM is making a comeback in Metro.  Microsoft has used COM (specifically the IUnknown interface) for years as a means of exposing native interfaces, and they are simply using that rather than reinventing the wheel.  There are no type libraries, rather interfaces are described in a modified version of the .NET metadata format called winmd.

So, if you’re thinking about accessing the WinRT from FoxPro or other environment using COM, you can forget about that.  In fact, this whole notion of automating other applications is absent from Metro.  You cannot directly start another application and communicate with it from Metro.  This applies to both Metro and desktop apps.  You can send info to another Metro app via “contracts”, such as the Share contract in Metro.  But you can only use contracts provided by Microsoft, and these contracts can only be initiated by the user, not in code.  If you do need to communicate with another app, even on the same machine, then you’ll need to use network protocols, such as IP sockets, http, or web services.

With all this hype, what is Metro replacing?  Something has to die, right?  I’m sure each of us will draw our own conclusions on that, but I will say that Microsoft always emphasizes the shiny new thing.  That doesn’t mean existing MS technologies will go away, or that MS will stop investing in those technologies.  At the same time, Microsoft is clearly investing heavily in Metro and will continue to do so, at least until the next shiny new thing comes along.  From a technical point of view, to the extent that you can port your code (based on restrictions) and that you choose to adopt the Metro design, Metro replaces almost everything.  If every desktop app were rewritten in Metro, then it could even replace Windows as a whole.  It’s hard to know what Microsoft’s aspirations are in this regard, but based on the targeted nature of Metro and its capabilities, I don’t see this happening, not for a long, long time, if ever.  From the point of view of each technology…

.NET: I can unequivocally say that the .NET Framework is here to stay.  Since Metro is only client-side technology, you will need something on the server side, and Microsoft will continue to push .NET for that.  When building C#/VB apps, Metro does use the .NET Framework, however it restricts you to a subset of functionality.  For example, you cannot use the System.Data namespace, which means no ADO.NET, which means you can’t access a database directly from Metro.  You’ll need to build the data access into the server side using .NET.  For what it’s worth, I believe Silverlight has the same restriction.  Microsoft seems to be deciding what the .NET restrictions are based in part on what they did in Silverlight (more on that topic at http://channel9.msdn.com/events/BUILD/BUILD2011/TOOL-930C).  Lastly, do I even need to mention ASP.NET?  Browser-based web apps aren’t going anywhere.

Silverlight/WPF: As far as being deprecated, I worry about Silverlight the most.  MS will be pushing Metro on the desktop and HTML5 through the browser.  Some will say that WPF is already dead.  On the other hand, PhotoShop was shown at the keynote and given as an example of an app that would NOT be appropriate for Metro, due to its dense UI design with a focus on productivity.  Many line-of-business applications could be described in the same way, so there is still a place for these technologies.  As it stands, there are new versions coming out for both, but beyond the next version, we don’t know.  Now that the XAML group is part of Windows, Metro will no doubt get the lion’s share of the resources, but I hope investment continues on Silverlight and WPF.

Win32/C++:  For the most part, C++ developers will be using WinRT in Metro rather than the Win32 API.  MS does allow access to a subset of Win32 APIs that have functionality not addressed in WinRT (http://msdn.microsoft.com/en-us/library/windows/apps/br205757%28v=VS.85%29.aspx), but at this level, WinRT and Win32 really are separate worlds.  That said, Win32 is the most used API on the planet. Even if MS doesn’t invest another cent into it, it will be here a long time.

Let’s talk about preserving your existing investments.  Microsoft is focused on making sure your existing skills can be used when building Metro apps.  That is, as long as those skills include HTML/JS, C#/VB, or C++.  You might even be able to port existing code into Metro, but it’s not copy and paste, and it has to adhere to the restrictions.  Microsoft demoed porting existing XAML and code from Silverlight and Windows Phone apps that were already written in the MVVM pattern used by Metro.  If you want to move from a Windows Forms UI, I doubt there is much you can keep, and you’ll be rewriting the UI in Metro.  From FoxPro, you don’t get to keep anything, except what you use on the server side.  I’m not a C++ developer, but I imagine porting C++ code would involve replacing Win32 calls with WinRT functionality. I don’t know how feasible that is, so you may be able to bring in code that doesn’t reference Win32 (good luck finding some) and rewrite the rest to use WinRT.

As far as compiled libraries, you can’t just add a reference to a .NET DLL in a Metro app.  You can, however, create a “Portable Library” that can be called from both Metro and standard .NET, as long as the library sticks to the Metro subset of .NET.  I don’t know how this works in C++, but it may be the same story.  MS showed bringing the Boost library into a Metro app, but I don’t know if that was Boost source code or a compiled library.

Moving on to user interface… Microsoft is providing developers with clear design guidelines for Metro apps.  Designers may not like being told how to design their apps, but I don’t think it is a requirement that you follow the Microsoft rules.  Personally, I am glad that Microsoft is providing guidance on Metro design, because we got no such guidance with WPF or Silverlight.  How many times have you seen WPF or Silverlight session where the speaker says “I’m not a designer…”, and then proceeds to show a crappy looking UI that makes you wonder why you would want to use the technology at all? With Metro, I can use the MS templates, follow the guidelines, and end up with an attractive, functional app.  If I want to do something extra special, then I can get a professional designer involved.

What about deployment of Metro apps? You will be able to use “side-loading” to test and debug your apps on a limited number of devices.  Otherwise, you can’t directly install your Metro app on a device.  It must be deployed through the online Windows Store.  Each app you upload will be certified against a series of tests to ensure compatibility and compliance.  So, if you’re thinking about using some tricks to get around the restrictions I’ve already mentioned, that may work on your machine, but the certification tests will fail and you won’t be able to deploy your app.  Microsoft hasn’t released details yet, but most expect they will do the same as the Windows Phone store and take 30% of the price of Metro apps.  You may have heard that the store will be free, but I believe that is only for the listing of Windows desktop (non-Metro) apps, in which case, MS just links to your site, but doesn’t handle deployment.  There will also be an enterprise deployment option for companies that want to deploy apps internally.  Apple charges $299/year so that you can distribute code YOU write to devices YOU purchased.  That’s not a lot of money, but it just rubs me the wrong way, so we’ll see what Microsoft does in this regard.

So, Microsoft has Metro locked down pretty tight.  Metro limits you to a subset of .NET. You can’t automate other applications or reference existing “desktop” DLLs.  MS forces you to deploy through their store and takes 30% off the top.  This is not characteristic of the Microsoft we have worked with all these years, but they are following Apple’s lead.   At the same time, by exerting this level of control, Microsoft can ensure the integrity, stability, and security of the Metro experience.   The restrictions prevent outside code from polluting and compromising the Metro environment.  If that all seems a little too Big Brother to you, you still have the option of creating Windows desktop and HTML applications without the restrictions, both of which can still be touch enabled.

With all of this in mind, should you run out and rewrite all of your applications for Metro?  Every day, I work on a FoxPro line-of-business app with a heavy emphasis on data entry and productivity.  The fact that we’re still using FoxPro should tell you that we don’t jump at every new technology that comes out of Microsoft.  But, even if this were a WPF or Silverlight app, I don’t think it would be a good candidate for the Metro style.  Maybe that’s a lack of imagination on my part, but displaying info one screen at a time or with a bunch of panning or scrolling would cause a large hit to productivity.  Now, are there pieces of our app that I could expose to a wider audience using a simpler interface with touch capabilities?  Yes.  And the developer and user experience in Metro is compelling enough that I might just target it over an HTML interface that works on multiple devices.  I’m looking at Metro as an environment where I can offer new apps and experiences to users when it makes sense, not as a replacement for existing technologies.

Posted on

C# 4.0 Gets dynamic

I’ve been watching some of the PDC 2008 videos online.  One of the highlights is The Future of C# by Anders Hejlsberg, and I highly recommend it to anyone that’s interested in .NET.  Most of the session focuses on the dynamic capabilities that are coming to C# 4.0.  The .NET Common Language Runtime (CLR) was built primarily with static typing (aka “strong typing”) in mind, in which every variable must be explicitly declared and assigned a type (string, integer, etc.).  Microsoft recently built the Dynamic Language Runtime (DLR) to support dynamic (non-static) languages, such as Python and Ruby, and they are using the DLR to bring some dynamic features to C#.

To you strong-typing zealots, there’s no need to be alarmed.  C# is not transforming itself from a static to a dynamic language.  There is a gap between static and dynamic languages, and the focus is on closing that gap and improving the interaction.  It just so happens that FoxPro is a dynamic language…

To illustrate the problem, here is a simple VFP class I wrote that finds a customer and creates an object for the customer using Scatter:

Define Class Customers As Session OlePublic

oCustomer = NULL

Procedure GetCustomer(lcCustomerID As String)
Local loCustomer

If !Used("Customers")
 Select 0
 Use (Home(2) + "Northwind\Customers")
Else
 Select Customers
EndIf
Locate For CustomerID = lcCustomerID
Scatter Name This.oCustomer Memo

EndProc

Procedure Destroy

Use In Select("Customers")

Endproc

Enddefine

I compiled the class into a COM DLL and imported it into my C# project.  (For more on that, see Rick Strahl’s article: .NET Interop for VFP Applications.)  Since This.oCustomer is created dynamically at runtime, FoxPro cannot include it in the type library.  Therefore, to access any properties of the oCustomer in C#, you have to use “reflection”.  Here’s the C# code:

string CustomerID = "ALFKI";
netcomtest.Customers oCustomers = new netcomtest.Customers();

oCustomers.GetCustomer(CustomerID);
object oCust = oCustomers.OCUSTOMER;
//use reflection to access object properties
object CompanyName = oCust.GetType().InvokeMember("COMPANYNAME", BindingFlags.GetProperty, null, oCust, null);
object ContactName = oCust.GetType().InvokeMember("CONTACTNAME", BindingFlags.GetProperty, null, oCust, null);
//display company and contact name
MessageBox.Show(CompanyName.ToString() + ContactName.ToString());

What a mess!  If I wanted to access all of the properties on the object, this would get very tedious.  C# 4.0 makes the process easier by introducing a new “dynamic” type.  This tells C# to resolve the type of the variable at runtime (just like Fox would), rather than at compile time.  If I understand Anders correctly, here’s what the new code should look like :

string CustomerID = "ALFKI";
netcomtest.Customers oCustomers = new netcomtest.Customers();

oCustomers.GetCustomer(CustomerID);
//create dynamic reference to object
dynamic oCust = oCustomers.OCUSTOMER;
//display company and contact name
MessageBox.Show(oCust.CompanyName + oCust.ContactName);

Now, isn’t that better?  I can actually understand this code.  I can access all the properties of oCust directly, just like I would in FoxPro.  It’s nice to see that COM Interop is one of the things that Microsoft is still improving.

Anders also showed some things they are working on beyond C# 4.0.  Fast forward to the 60 minute mark in the video to see the cutting-edge stuff they are working on.  In short, they are rewriting the compiler, so they can do stuff like put code into a string variable and evaluate/execute it at runtime.  Fantastic!  Anders took it a step further and showed C# commands being executed as he entered them into a window.  Unbelievable!  It’s amazing what they can do these days!  Seriously, should you find yourself working with C# in the future, it will be nice to have some capabilities we’ve grown to love in VFP.