C# on dwmkerr.com

Unit Testing the Windows Registry

Sat, 05 Sep 2020 00:00:00 +0000

I’ve been updating some of my .NET projects recently (read more about this in Modernising .NET projects for .NET Core and beyond!). In one of these projects I have to work with the Windows Registry - which can be quite painful, particularly if you want to make your code unit test friendly.

In this article I’m going to introduce a simple approach to make testing the registry a little easier. If you are just interested in the code and not so much the story behind it, you can skip straight to the project at github.com/dwmkerr/dotnet-windows-registry.

Why Bother Testing?
Why Bother Testing the Registry?
Talk is cheap, show me the code
The Registry is not easily testable
The Testable Registry
Go forth and test

Why Bother Testing?

There is a wealth of material available on the subject of testing. The value different of different types of tests has been discussed at length and is a constant source of debate. If you are interested in reading about testing in more detail, I recommend Martin Fowler’s Software Testing Guide.

I’m not going to weigh in on the debate of the value of different tests. Instead, here are the specific issues I faced when working on my SharpShell project (which is where my registry testing project originated):

This is an open source project with a number of users, who would be inconvenienced if things broke from one release to another
There are a number of scenarios in the project which involve extensive modification of the registry
Even very small mistakes in the way the registry is accessed can break the code
Manually testing these scenarios is very time consuming…
…and I have very limited time to work on this project
I want to encourage others to contribute, but have confidence their changes will not cause unexpected failures

In this project, being able to test the changes my code is going to make to the registry has been valuable. Whether it is for your own projects will depend on your own circumstances.

Why Bother Testing the Registry?

The Registry is essentially a database. A problematic database. It has a complex schema, which has evolved over time. The schema for certain features (such as Windows Shell Extensions) has changed considerably over the years. It is often messy - many programs will write to it and programs can overwrite values.

One thing I have discovered over my years maintaining the SharpShell project is that registry access is one of the most brittle elements of the code. It is risky, it can have unexpected consequences.

There are a few things which should cause anyone working with the registry to seriously consider testing:

What do you do if the keys you are accessing have been modified by other programs?
What if your own programs have written incorrect data?
Is your code going to run on different versions of Windows, which might use the registry in different ways?
Registry access is security sensitive - does your code run with the appropriate permissions to access what it needs to access?

The registry is a database, but it is not an ACID database, meaning you can quite easily end up writing data in an inconsistent format (for example, if your program crashes before it has written all of the data it needs to). It has very limited access control - there is no way to limit other privileged programs overwriting or corrupting your data.

Hopefully covers some of the reasons it is worth testing the registry. Now lets see some code.

Talk is cheap, show me the code

Here’s an example of what I want to be able to do:

[Test]
public void Register_Server_Associations_Uses_Appropriate_Class_Id_For_Class_Of_Extension()
{
 // Pretty important test. Given we have a file extension in the registry, assert that we
 // register an extension with the appropriate ProgID.

 // Prime the registry with a progid for *.exe files.
 _registry.AddStructure(RegistryView.Registry64, string.Join(Environment.NewLine,
 @"HKEY_CLASSES_ROOT",
 @" .exe",
 @" (Default) = exefile",
 @" Content Type = application/x-msdownload",
 @" exefile",
 @" (Default) = Application"
 ));

 // Register a context menu with an *.exe association.
 var clsid = new Guid("00000000-1111-2222-3333-444444444444");
 var serverType = ServerType.ShellContextMenu;
 var serverName = "TestContextMenu";
 var associations = new[] { new COMServerAssociationAttribute(AssociationType.ClassOfExtension, ".exe") };
 var registrationType = RegistrationType.OS64Bit;
 ServerRegistrationManager.RegisterServerAssociations(clsid, serverType, serverName, associations, registrationType);

 // Assert we have the new extention.
 var print = _registry.Print(RegistryView.Registry64);
 Assert.That(print, Is.EqualTo(string.Join(Environment.NewLine,
 @"HKEY_CLASSES_ROOT",
 @" .exe",
 @" (Default) = exefile",
 @" Content Type = application/x-msdownload",
 @" exefile",
 @" (Default) = Application",
 @" ShellEx",
 @" ContextMenuHandlers",
 @" TestContextMenu",
 @" (Default) = {00000000-1111-2222-3333-444444444444}")
 ));
}

This test looks a little complex, but the details don’t matter. What matters is the flow, which is just:

Given a particular existing structure in the registry…
…when I call a certain API…
…then I expect a certain set of changes to have been made

Should be easy right? Unfortunately, it’s not as easy as this.

The Registry is not easily testable

The .NET Framework Registry classes are not written with testing in mind. This is not surprising - they are just wrappers around the Win32 Registry APIs. These are APIs which have been around for a while, they have a very well-defined goal, which is to provide access to the registry. They were not written with unit testing in mind.

There are in general two approaches which can be taken to testing side effects. Side effects are changes to state outside of your function or code’s state - such as the file system, databases and so on. These approaches are:

Test the System: We allow our tests to change the external system, making sure to prepare it in advance, read the changes, then clean up afterwards
Mocks the System: We make sure our code doesn’t touch the external system when it is testing, we test a mock only and assert that the mocked code makes the expected changes

The first approach is arguably better - you are really asserting that the expected changes have been made. But it is also complex - you have to clean up after yourself, you run the risk of your tests actually changing (or even breaking your system) and you make it harder to have other developers easily run the tests. Some systems can mitigate this - for example, with some databases you could test in the context of a transaction which you never commit. But the registry offers no such capabilities.

The second approach is more common and in general a little easier. It doesn’t cause side effects, but still allows us to at least ensure we are going to attempt to make the expected changes.

To mock a service under test in .NET, we generally need to be calling functions on an interface. There are some ways around this (fakes, modified assemblies, etc) but they are problematic. However, the .NET Registry classes are not exposed as interfaces. This is not a failure of the framework, arguably adding interfaces without a specific need is an anti-pattern. But it does make mocking the registry hard.

The easiest way around this problem (at least in my opinion) is to wrap the registry access in an interface, then provide two implementations. One which uses the standard registry access methods, and one which mocks the changes to the registry in an isolated and testable fashion. In my SharpShell code this was the approach I took, and I have just extracted this code into its own library to help others who might want to use the same approach.

The Testable Registry

The solution I’ve used is fairly simple. You can see the code at:

github.com/dwmkerr/dotnet-windows-registry

Instead of making calls to Regsitry or RegistryKey, you make calls to IRegsitry or IRegsitryKey. Then use the appropriate implementation. There are examples in the project documentation, but here’s how it looks in a nutshell.

First, make sure the code you have which access the registry does it via the IRegistry interface:

public class Greeter
{
 public Greeter(IRegistry _registry)
 {
 _registry = registry;
 }

 public void Greet(string name, string greeting)
 {
 using var key = registry.OpenBaseKey(RegistryHive.CurrentUser, RegistryView.Registry64);
 using var subkey = key.OpenSubKey("Greetings");
 subkey.SetValue(name, $"{greeting}, {name}!");
 }

 private IRegsitry _registry;
}

Now in your program, create your class and provide it with a WindowsRegistry class:

var greeter = new Greeter(new WindowsRegistry());
greeter.Greet("Billy", "Howdy");

And you can test your code like so:

var registry = new InMemoryRegistry();
var greeter = new Greeter(registry);
var print = _registry.Print(RegistryView.Registry64);
Assert.That(print, Is.EqualTo(string.Join(Environment.NewLine,
 @"HKEY_CURRENT_USER",
 @" Greetings",
 @" Billy = Howdy, Billy!")));

That’s the basics.

Go forth and test

There is a degree of inconvenience in having to use the interface rather than using the out-of-the-box implementation. This is a trade-off you will have to make to allow your code to be testable, and whether it is a worthwhile trade will depend on your project.

The pattern of not relying on concrete implementations and instead providing interfaces to classes is known as Dependency Injection. There are technologies which attempt to assist with this pattern, known as Inversion of Control Containers - whether they make life easier to simply move complexity around (see The Law of Conservation of Complexity). But if you are already using an IoC container then adopting this library and pattern will be trivial.

That’s it - the code has been internal to the SharpShell project for years and I have only just extracted it into its own library. I’ll be using it in my ComAdmin project (which is also being extracted from SharpShell). Given that it is new it might change a bit, and I’d love any feedback:

https://github.com/dwmkerr/dotnet-windows-registry

Modernising .NET projects for .NET Core and beyond!

Wed, 01 Jul 2020 00:00:00 +0000

The world of .NET is going through a transformation. The .NET Framework is reaching end of life, .NET Core is an increasingly feature rich and robust platform to develop solutions which target Linux, MacOS, embedded devices, containers and more. There’s also the .NET Standard.

But what does this mean for .NET Framework projects? In this article I’ll describe how to modernise your .NET Framework projects for .NET Core, the .NET Standard and .NET 5, which is planned to be released this year. I’ll also explain the high level differences between the platforms and what the consequences of upgrading are for consumers, developers and maintainers.

The .NET Framework, .NET Core and the Future
The Challenge: Modernisation and Compatibility
The Modernisation Process - Introducing our two Villains
The Key Learnings

The .NET Framework, .NET Core and the Future

There’s a lot which has been written on this topic, but it can still be a little overwhelming to understand just how all of these things fit together.

Here’s a simple visual I’ve created to try and put things into context:

I’m only going to cover the bare essentials - but there are links to further reading on each topic if you want to go deeper. This article is mainly going to be focused on the practicality and consequence of migration and re-targeting.

First, the .NET Framework.

The .NET Framework was created in 2002 as set of unified tools and standards to allow developers on the Microsoft Platform to more quickly build solutions, provide interoperability between languages and more. Read more about the .NET Framework.
The .NET Framework rapidly gained popularity, partly due to the convenience of developing in C# rather than Basic or C/C++. C# provided a more developer friendly language than C or C++ for many use cases, and was heavily inspired by Java. Read more about C#.
With the increase in popularity, the .NET Framework started to have more frequent releases and became a standard part of the Windows operating system, installed out of the box rather than on-demand if needed.
However - the .NET Framework only functioned on Microsoft Windows, which greatly limited its potential uses cases, even as more and more engineers used it for Web, Client Applications and mobile.

Enter .NET Core.

Microsoft signaled a radical switch in their strategy with the appointment of Satya Nadella, becoming increasingly focused on open source, and more importantly, deciding that the Microsoft development toolchain should not force users to use Windows as their execution environment
.NET Core was developed as a lightweight version of the .NET Framework, which could run on multiple platforms - including Linux and MacOS. Read more about .NET Core.
In a short period of time .NET Core became more and more feature rich, providing a lot of capabilities for web developers and front-end application developers.

The challenges of divergence and the .NET Standard.

As .NET Core became more feature rich, the API became closer to the .NET Framework - but they are still fundamentally different runtimes. A binary compiled for the .NET Core does not run on the .NET Framework and vice-versa.
To deal with this issue, Microsoft developed the .NET Standard - a specification of a set of APIs. If a runtime offered these APIs, then solutions built on any runtime which meets the standard could run on any compliant platform.

What does this mean? Basically, the table below shows the consequences of this. If you build on .NET Core 2.0 (for example), you can also run on the .NET Framework 4.6.1. Mono 5.4, Unity 2018.1 and more, because all of these runtimes implement the .NET Standard 2.0.

Of course, some features are always going to be very platform specific, so the standard started out small but has grown over time.

Moving to convergence and .NET.

Given that the later versions of the .NET Framework and .NET Core actually follow the same standard, the platforms are actually starting to become more and more similar.
They are becoming so similar that it no longer makes sense to maintain them separately. The next major version of both platforms is .NET 5. This is a new runtime which is the next version of .NET Core and the .NET Framework.

This means that the .NET Framework and .NET Core are going to converge into a single platform, which will be wonderful for developers and simplify a complex landscape.

But what does this mean if you have .NET Framework projects? How do we modernise, and do we have to make trade-offs around compatibility?

The Challenge: Modernisation and Compatibility

I have a number of projects which target the .NET Framework. On all of these projects I have had multiple requests to migrate to the .NET Core, but I have had to hold off on this work until I could really understand in detail a few things:

What would this mean for consumers of the libraries? Would they have to change the platform they use? Could this break things for them?
What would this mean for developers on the platform? Would they need to change their development environment? Would this cause problems?
What would this mean for maintainers of the libraries? Would this greatly increase build and deployment complexity?

Finally I have found the time to be able to start to address these issues in detail - hopefully the learnings will be useful to anyone who is maintaining a .NET codebase and thinking about the future.

The Modernisation Process - Introducing our two Villains

There are two key projects I wanted to modernise. They are both reasonably well used, complex, and have some potentially serious complexities for multi-platform builds.

SharpGL is a library that allows developers to use OpenGL in .NET applications. The big challenge? OpenGL is cross platform, but SharpGL specifically provides an interface to the Windows version of OpenGL. Can this possibly be made more future-proof? Could it ever target other platforms?

SharpShell is a library that allows developers to build ‘Shell Extensions’ for Windows. Shell extensions are customisations to the Windows user interface, so would not be portable across platforms, but I still want to ensure that the project is future proof.

What would be the experience with these two projects? I have other .NET projects, but they are far less popular and much more simple, my instinct is that if I can work through the process with these projects, the others should be more straightforward.

These are the steps I’ve followed to modernise. I’ll finish the article with a summary of the key learnings.

Step 1 - Understand the Domain

I cannot stress this enough. In all meaningful technology work, understand the domain you are dealing with. A quick Google on how to migrate, or following the formal migration guide was not enough for me. I knew I had to actually understand, at a reasonably detailed level, the differences in the runtime, the trade-offs, the process, the complexity.

This article is the result of that work - sometimes writing about a topic is the best way to force yourself to learn it.

Making changes rapidly and waiting to see what the consequences are can often work for small projects, internal tools and so on, but for a library which is relied upon by others is not good for the community. The last thing I wanted to do was make changes which had unintended consequences for users. So making sure that I learnt about this space, how things work under the hood, and what the expected changes in the future are was critical.

Hopefully for others the process of understanding the domain will be a little easier with this article to cover the high level topics. During my actual process of writing and migrating, I went a lot deeper than this article goes.

The key document to follow to actually execute the migration is the excellent official .NET Framework to .NET Core Porting Guide.

Step 2 - Understand the Goal - Multi-Platform Builds

Given the understanding of the domain, it made it much easier to understand what the required steps would be. Essentially, all that would be needed would be to target a version of the .NET Framework which adheres to a recent version of the .NET Standard. Once this was done, in theory the project could be built for the .NET Framework and for .NET Core, and also be ready for the upcoming .NET 5 release.

Multi-platform builds are supported in Visual Studio 2019. These builds allow us to have a single codebase, but build libraries for multiple platforms (i.e. the .NET Framework and .NET Core). The resulting binaries can be packed as a single package, and when consumers install the package, the appropriate library is installed.

This introduces the first of the significant consequences - modernising your project means you must migrate it to Visual Studio 2019.

In the past, this might have been more of an issue, licenses for Visual Studio were expensive, and many organisations were locked onto specific versions for compatibility issues (or because they were slow to upgrade). This seems to be the case less often nowadays, but is still an important consideration.

My projects were using Visual Studio 2017. This is how the project properties looked:

Unsurprisingly the .NET Standard isn’t mentioned. Time to upgrade to 2019. While I installed it I could reminisce about the excitement of buying Visual C++ .NET Learning Edition:

And try and remember what is was like to be a 15 years old. I wonder if that box set is still kicking around somewhere, I want to see it again. So much has changed. But long install processes for Visual Studio haven’t, at least they kept that:

When installing, remember to enable the .NET Core features.

Step 3 - Migrate Projects “Leaf-wise”

As per the Porting Guide, we need to migrate each of the projects which make up the solution, starting with the ’leaves’ (projects which don’t depend on other projects) and then moving up the tree to the ‘root’ projects (projects which are depended on by others).

Visually, for a solution like SharpGL, that would mean the projects will need to be converted in the following order:

I was expecting each project to have quite different experiences:

SharpGL.Serialization is just a set of classes which load data from files. In theory, this library should become completely portable.
SharpGL.WPF and SharpGL.WinForms are specifically for Windows front-end technologies. I expected these to be able to be ported, but don’t expect them to work on other platforms (in the future there might be SharpGL.OSx, or SharpGL.Gnome, who knows)
SharpGL.SceneGraph is a set of classes which represent 3D scenes - things like lights, cameras, materials and so on. I expect some of this to ‘just work’, but things like image loading to perhaps need some tweaking.
SharpGL is just a wrapper around the Windows opengl32.dll library. I can’t imagine this working anywhere but Windows, but how would the project structure porting go and would it build?

The details on how to migrate a project are in the Porting Guide, but the general approach will be:

Attempt to convert to the latest project format with the try-convert tool
Re-target the project to the .NET Framework 4.7.2 (the first version which supports the .NET standard)
Repeat for projects which this project depends on, walking the tree of projects to the root
Run the Portability Analysis tool to see if there are APIs which are not available on certain platforms

This is how you project might look after migration, having run the try-convert:

Now we just need to edit the project files and change the line:

<TargetFramework>4.7.2</TargetFramework>

To:

<TargetFrameworks>netcoreapp2.0;netcoreapp3.0;netcoreapp3.1;net40;net45;net472</TargetFrameworks>

The targets you will choose will depend on the APIs you want to use. There is an Portability Analysis extension available which can build a portability report, here’s what one looks like:

This will also show the specific APIs which are not compatible with specific targets:

Now it’s time to move to the next step.

Step 4 - Refactor, Rinse, Repeat

This is the tricky part. You’ll now need to work out whether you want to remove API calls which are not portable, try and use alternatives, or conditionally compile the code for different platforms.

If you are using non-portable APIs you may need to use conditional blocks to execute different code depending on the framework used. The Target frameworks in SDK-style projects guide shows how to do this.

You may also have to manually edit the project file to ensure that certain dependencies are only used for certain targets. You solution file and dependencies may end up looking something like this:

Once you have reloaded the project you’ll see your dependencies can now be specified on a per-framework basis, and a build generates assemblies for each of the targets:

This process might be simple, or complex, depending on the nuances of your project. For me it was fairly iterative - starting by targeting only net40 (the original target framework which I’d used), then adding more and more targets.

Some targets will simply not be possible - for example .NET Core only supports WinForms and WPF from .NET Core 3.0 onwards; you won’t be able to build a WinForms or WPF assembly which targets a lower version, the framework doesn’t support it.

Step 5 - Update Your Builds

At this stage, having fixed compatibility issues, you should have code which builds in Visual Studio.

Now I would recommend porting all of your build code to use the dotnet build system. This is going to maximise the portability and future-proof your project, you’ll be able to run the builds on multiple platforms and are using the preferred standard tool (msbuild will essentially become legacy).

The way I like to structure things personally is have a set of scripts which you can run to build, test and package the code locally. You can then call these scripts from you CI tool of choice to automate things, but still keep the logic in your own code, rather than hidden away in a build system.

For example, in my SharpGL project I have the following scripts:

Script	Usage
`config.ps1`	Ensure your machine can run builds by installing necessary components such as `nunit`. Should only need to be run once.
`build.ps1`	Build all solutions.
`test.ps1`	Run all tests, including those in samples.
`coverage.ps1`	Create a coverage report. Reports are written to `./artifacts/coverage`
`pack.ps1`	Create all of the SharpGL NuGet packages, which are copied to `./artifacts/packages`.

I updated my scripts to use the dotnet tool. For example, the ‘build’ script looks something like this:

# Run the build, hiding the documentation warnings for pinvoke code.
$buildCommand ="dotnet msbuild $PSScriptRoot\SharpGL.sln -noWarn:CS1591 -noWarn:CS1573 -t:Rebuild -p:Configuration=Release"
Write-Host "Running: ""$buildCommand"""
Invoke-Expression $buildCommand

And the ‘pack’ script looks like this:

dotnet pack --no-restore --no-build "$PSScriptRoot/Core/SharpGL/SharpGL.csproj" -c:Release
dotnet pack --no-restore --no-build "$PSScriptRoot/Core/SharpGL.SceneGraph/SharpGL.SceneGraph.csproj" -c:Release
dotnet pack --no-restore --no-build "$PSScriptRoot/Core/SharpGL.Serialization/SharpGL.Serialization.csproj" -c:Release
dotnet pack --no-restore --no-build "$PSScriptRoot/Core/SharpGL.WinForms/SharpGL.WinForms.csproj" -c:Release
dotnet pack --no-restore --no-build "$PSScriptRoot/Core/SharpGL.WPF/SharpGL.WPF.csproj" -c:Release

The actual scripts are a little more complex. But the key thing here is that I can run any part of the CI/CD process locally (to test, debug and so on) or on a CI/CD platform.

You will most likely have to conditionally reference certain components. The dependency for net40 might be different to that for netcoreapp3.0. You’ll see that in many of my project files there is now code like this:

<ItemGroup>
 <Reference Include="System.Design" Condition="'$(TargetFramework)' == 'net40'" />
 <Reference Include="System.Design" Condition="'$(TargetFramework)' == 'net45'" />
 <Reference Include="System.Design" Condition="'$(TargetFramework)' == 'net472'" />
 <Reference Include="System.Windows.Forms" Condition="'$(TargetFramework)' == 'net40'" />
 <Reference Include="System.Windows.Forms" Condition="'$(TargetFramework)' == 'net45'" />
 <Reference Include="System.Windows.Forms" Condition="'$(TargetFramework)' == 'net472'" />
</ItemGroup>
<ItemGroup>
 <PackageReference Include="Microsoft.CSharp" Version="4.7.0" Condition="'$(TargetFramework)' == 'netcoreapp3.0'" />
 <PackageReference Include="Microsoft.CSharp" Version="4.7.0" Condition="'$(TargetFramework)' == 'netcoreapp3.1'" />
 <PackageReference Include="Microsoft.CSharp" Version="4.7.0" Condition="'$(TargetFramework)' == 'net45'" />
 <PackageReference Include="Microsoft.CSharp" Version="4.7.0" Condition="'$(TargetFramework)' == 'net472'" />
 <PackageReference Include="System.Data.DataSetExtensions" Version="4.5.0" Condition="'$(TargetFramework)' == 'netcoreapp3.0'" />
 <PackageReference Include="System.Data.DataSetExtensions" Version="4.5.0" Condition="'$(TargetFramework)' == 'netcoreapp3.1'" />
 <PackageReference Include="System.Data.DataSetExtensions" Version="4.5.0" Condition="'$(TargetFramework)' == 'net45'" />
 <PackageReference Include="System.Data.DataSetExtensions" Version="4.5.0" Condition="'$(TargetFramework)' == 'net472'" />
</ItemGroup>

In my case quite a bit of trial and error was needed to find the appropriate references for each platform.

Step 6 - Simplify!

One benefit I have found during this process is that you can simplify your projects. You no longer need any kind of ‘automated NuGet restore’ functionality. This means you can remove code like this from your project files:

<Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
 <PropertyGroup>
 <ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
 </PropertyGroup>
 <Error Condition="!Exists('..\packages\NUnit.3.11.0\build\NUnit.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\NUnit.3.11.0\build\NUnit.props'))" />
 <Error Condition="!Exists('..\packages\NUnit3TestAdapter.3.10.0\build\net35\NUnit3TestAdapter.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\NUnit3TestAdapter.3.10.0\build\net35\NUnit3TestAdapter.props'))" />
</Target>

You can also remove your project.json as all of the data is now in the csproj file.

Another nice update is that you no longer need to maintain an AssemblyInfo.cs file; you can keep all of your assembly metadata in the csproj file.

Finally, you can almost certainly remove any nuspec files - all NuGet packaging data can also be embedded in the csproj file. For example, here’s what my SharpShell project metadata looks like:

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
 <PropertyGroup>
 <TargetFrameworks>netcoreapp2.0;netcoreapp3.0;netcoreapp3.1;net40;net45;net472</TargetFrameworks>
 <OutputType>Library</OutputType>
 <!-- The following properies are used to manage how the project is packaged. -->
 <PackageId>SharpShell</PackageId>
 <Copyright>Copyright (c) Dave Kerr 2020</Copyright>
 <PackageProjectUrl>https://github.com/dwmkerr/sharpshell</PackageProjectUrl>
 <RepositoryUrl>https://github.com/dwmkerr/sharpshell</RepositoryUrl>
 <Version>3.1.1.0</Version>
 <Authors>Dave Kerr</Authors>
 <Company>Dave Kerr</Company>
 <PackageTags>Shell;SharpShell;COM;Context Menu;Icon Handler</PackageTags>
 <Description>SharpShell is a framework that lets you build Windows Shell Extensions using .NET Core or the .NET Framework.</Description>
 </PropertyGroup>
 <!-- ...snip... -->
</Project>

This helps to keep a lot of the project dependency and property data in one place and is probably more convenient for many users.

You can see the Pull Request for SharpGL to see how the project files were updated in this case. You can also see the SharpShell Pull Request. The SharpShell version is still work in progress at the time of writing.

Step 7 - Test, Test, Test

Now for the fun part. You are going to really have to test the new packages on each platform. Sadly, this kind of migration is not something which will have issues exposed via unit tests, you’ll need to create test projects which import your packages, ideally for each platform, and make sure they work. There could be runtime errors, particularly if you have made mistakes with the references.

Many issues will be caught at compile time - some will not.

Here’s a screenshot of me having fun trying out the .NET Framework 4 package for WinForms, and the .NET Core 3.1 package for WPF:

How you test your packages will be very dependent on what you are building. If it is highly platform specific then you will likely have to do lots of testing. If it is fairly self-contained code then you might be able to get away with some basic smoke testing.

Step 8 - Document Compatibility

If you are supporting multiple platforms and frameworks, it’s going to be a lot of help to consumers of your code if you can be very clear about what is supported.

This may be more complex than you think. Your library may run fine as part of a .NET Core Console Application on Windows - but does it work on MacOS? What about Linux?

Here’s a screenshot I would never have imagined when I started the SharpGL project - a terminal application running on MacOS which is using the SharpGL.Serialization library to load geometry from a file:

Now of course for something like SharpGL to run on a Mac or Linux, a lot more work would be needed. SharpGL is at its core nothing more than a wrapper around opengl32.dll on Windows, on other platforms there are no DLLs, but OpenGL is still available. So support is possible, but not ready yet. So at this stage, docmenting what you know works as well as what doesn’t will be really helpful.

You might also want to preserve your ‘pre-migration’ code in a separate branch, in case you have users who for some reason have issues migrating and need to use an older version. For SharpGL, I updated the project page to indicate compatibility, what has been tested and so on:

The Key Learnings

Here are the key learnings which stood out for me as I worked on migration of these projects.

Consumer Experience

If you are careful, you don’t have to break anything for consumers - with multi-targeting you can still target older frameworks.
You can potentially greatly increase the compatibility of your projects by offering support for .NET Core.

Developer Experience

You need to upgrade to Visual Studio 2019…
…however, you can use Visual Studio for Mac or even the command-line to build across many platforms.

Maintainer Experience

You will have a much larger set of potential consumers, but you will likely find bugs which are framework or platform specific.
You will likely need to work on migrating your project files and use the latest dotnet tooling.
You should be careful to document known compatibility issues.

All in all, the process was less painful than I expected. Now that this work is done I can focus on more exciting things, such as potentially getting projects like SharpGL working on Linux or MacOS, which is much more exciting.

As always, questions, comments, suggestions, rants, anything are welcome!

The pull request which migrates the SharpGL project and SharpShell projects are below:

Useful References

Context Menu for Trello

Thu, 27 Jun 2013 05:40:58 +0000

I’m on holiday at the moment, back in sunny England. Holiday may not be the right term really, I’m mostly working through charity stuff (for my charity Namaste - Children’s Homes Nepal) and company administration. I’m also starting working on a big new project, which is pretty exciting.

Anyway, I got a nice message from a fellow coder George Hahn who has put together a pretty cool project that lets you send files directly to Trello as an attachment to a card, or even as a new card. Here’s a screenshot of it in action:

It’s a nice project, you can check it out on GitHub:

What's also cool about this project is that it's the first project that someone's told me about that uses SharpShell. Many people have got in touch with me about SharpShell (in fact, the SharpShell Context Menus article on the CodeProject is very popular), but so far this is the first real-world project where the writer got in touch after the project is completed.

Thanks George, I look forward to seeing what else you’re working on!

Build Buttons for Facebook, Twitter, LinkedIn, GitHub and More!

Tue, 18 Jun 2013 02:34:59 +0000

Recently I’ve been working on a small project called Build Buttons. Build Buttons is a website that let’s you quickly create buttons for sharing and promoting content. You can use Build Buttons to create Facebook ‘Like’ or ‘Follow’ buttons, LinkedIn ‘Share’ buttons, Google +1 buttons, GitHub Star, Fork and Follow buttons and more. Here’s how it works.

First, go to www.buildbuttons.com:

Now choose the kind of buttons you want, in this example we’ll select ‘Social Media’ from the top menu:

On each category page, there’s a list of the different types of buttons that can be built. Social Media includes the ‘Share’ button set. Click ‘Build It!’:

Now just fill in the details to customise your buttons, enter a URL and select the sort of buttons you want to include. When you’re ready to see how your buttons look, choose ‘Build it!’:

You get a working preview of how your buttons look, and a text box that includes the HTML you need to drop into your webpage or blog, easy!

Build Buttons has quite a few different types of buttons you can create. You can:

Create a set of social media buttons
Create Facebook Like and Follow buttons
Create Google +1 buttons
Create LinkedIn Share buttons
Create GitHub Star, Follow and Fork buttons

Getting Paths for Files in NUnit Tests

Thu, 02 May 2013 05:22:45 +0000

When using NUnit, sometimes you will want to access files in the test project. These might be xml files with data, assembly references or whatever. Now typically, NUnit will actually copy the files it thinks it needs into a temporary location. This causes the problem that you can then do things like use a relative path to get files in the project. You can use manifest resource streams but sometimes this just isn’t suitable.

To get the path of the root of your test project, you can use the snippet below. Make sure you call it in a unit test fixture that’s actually in your test project, not from a class referenced in another project!

This class, ‘TestHelper’ can be included in a Unit Test project to let you quickly get the path to the test project.

[code lang=“csharp”]public static class TestHelper { public static string GetTestsPath() { return Path.GetDirectoryName(Assembly.GetExecutingAssembly().CodeBase).Replace(@"file:", string.Empty); } }[/code]

Introducing FireKeys

Mon, 11 Mar 2013 11:11:29 +0000

I don’t know when I learnt that Windows + E opened up Windows Explorer. It must have been a while ago. But it’s imprinted in my muscle memory, the number of times I hit that combo every day is probably quite high. But how many other hotkeys do I use? Asides from a few other functional ones, like Win + D, I don’t use hotkeys so much. And I got to thinking, I’d love to open Google Chrome with a hotkey just like I do with explorer.

So I wrote FireKeys - a lightweight application that lets you assign hotkeys to actions. These actions could be opening program, a folder or a URL, but the underlying model is designed to be extensible.

You can get the tool from the FireKeys page. There’s an article on how it was developed on the CodeProject, FireKeys - Open Programs, Folders and URLs with Hot Keys.

Spider Solitaire and Augmented Reality

Mon, 25 Feb 2013 16:16:20 +0000

A while ago, I made an implementation of Solitaire and Spider Solitaire using WPF and my Apex MVVM library. I wrote about it on the CodeProject, in an article called Solitaire and Spider Solitaire for WPF (imaginative title indeed).

Anyway, just recently I got a very interesting message from rupam rupam, who has made an augmented reality version of the project! In his application, you use your webcam to play the game physically by picking up cards with gestures. Other gestures, like thumbs up and thumbs down are bound to commands in the game - here’s a screenshot:

The project is called GesCard and as far as I know there isn’t a page showing the code - but there are more links on the YouTube video for the page. Check out the YouTube video with the link here https://www.youtube.com/watch?v=wCOjuPdBooI. Thanks to rupam for getting in touch and sharing this very cool code!

Creating Info Tip Handlers with .NET

Mon, 14 Jan 2013 03:47:44 +0000

I have just added an article to the CodeProject that discusses how to create Info Tip shell extensions in .NET. These extensions are used by the shell to customise the tooltips shown over shell items.

The article shows how you can use SharpShell to very quickly create these extensions, you can find it at: http://www.codeproject.com/Articles/527058/NET-Shell-Extensions-Shell-Info-Tip-Handlers.

So just how easy does SharpShell make creating Shell Info Tip Handlers? The answer is pretty easy indeed. The code below shows the full implementation of a Shell Info Tip Handler that changes the tooltips for folders to show the name of the folder and the number of items it contains:

[csharp]/// <summary> /// The FolderInfoTip handler is an example SharpInfoTipHandler that provides an info tip /// for folders that shows the number of items in the folder. /// </summary> [ComVisible(true)] [COMServerAssociation(AssociationType.Directory)] public class FolderInfoTipHandler : SharpInfoTipHandler { /// <summary> /// Gets info for the selected item (SelectedItemPath). /// </summary> /// <param name="infoType">Type of info to return.</param> /// <param name="singleLine">if set to <c>true</c>, put the info in a single line.</param> /// <returns> /// Specified info for the selected file. /// </returns> protected override string GetInfo(RequestedInfoType infoType, bool singleLine) { // Switch on the tip of info we need to provide. switch (infoType) { case RequestedInfoType.InfoTip:

 // Format the formatted info tip.
return string.Format(singleLine
? &quot;{0} - {1} Items&quot;
: &quot;{0}&quot; + Environment.NewLine + &quot;Contains {1} Items&quot;,
Path.GetFileName(SelectedItemPath), Directory.GetFiles(SelectedItemPath).Length);
case RequestedInfoType.Name:
// Return the name of the folder.
return string.Format(&quot;Folder '{0}'&quot;, Path.GetFileName(SelectedItemPath));
default:
// We won't be asked for anything else, like shortcut paths, for folders, so we
// can return an empty string in the default case.
return string.Empty;
}
}

} [/csharp]

As you can see, all of the COM interfaces are hidden away and handled for you, there is no ugly pinvoke code and no use of strange structures imported from Win32. SharpShell handles all of the plumbing for you.

SharpShell

Tue, 08 Jan 2013 16:28:05 +0000

SharpShell is a project that I have recently uploaded to CodePlex. This class library, and set of tools and samples, is designed to be a framework to enable rapid development of Shell Extensions using the .NET Framework. In time it may grow to contain some functionality for using Shell entities within managed applications (for example, allowing an Explorer context menu to be built dynamically for a given path).

Anyway, the code is all at sharpshell.codeplex.com. You can also see a nice article on the CodeProject that show’s how to create a Shell Context Menu Extension using C#, the article is at: .NET Shell Extensions - Shell Context Menus.

Above: An example of a Managed Shell Extension. This sample colours the icons for dlls differently, depending on whether they are native dlls or assemblies.

So far, in the repo on CodePlex there are also samples for Shell Icon Handlers (which customise icons in Explorer) and Shell Info Tip Handlers (which customise tooltips). Both of these extension types are fully supported in the current dev version and will be released in the next few days. There’s also a partially functioning Shell Property Sheet implementation which will be delivered in the subsequent version. The Shell Property Sheet introduces some particularly strange code - 32 and 64 bit C++ dlls are embedded as manifest resource streams and extracted as needed to provide access to C++ function pointers - ouch.

More to follow - check out the project and the article.

The GAC Manager

Sun, 29 Jul 2012 08:44:00 +0000

I have started a new project on CodePlex called 'GAC Manager'. This is a project that is in two parts, the first is a simple tool to allow users to manipulate their local global assembly cache, the second is an API that provides the core functionality.

Here's a screenshot of the tool in its current state:

An article on the project is available on the CodeProject at: http://www.codeproject.com/Articles/430568/A-GAC-Manager-Utility-and-API

The project itself is at: https://github.com/dwmkerr/gacmanager

As always, comments, feature requests and so on are welcome!

Apex Part 2 - Adding Commands to an MVVM Application

Tue, 15 May 2012 07:43:00 +0000

In Part 2 of my video tutorial series on using Apex I show you how you can add commands to an MVVM application. Commands let you rapidly add functionality to a ViewModel, whilst still maintaining separation from UI.

A CodeProject article to accompany this video will be published shortly.

Apex Part 1 - Getting Started with the Apex SDK

Mon, 23 Apr 2012 05:35:00 +0000

Create an MVVM application in minutes with the new Apex SDK!

The video below shows this in action, see what you think.

There is also an accompanying article that describes what's going on. As always, would love to hear feedback!

http://www.codeproject.com/Articles/371217/Apex-Part-1-Create-Your-First-MVVM-Application

Come on MS - Improve MFC

Thu, 19 Apr 2012 09:02:00 +0000

Loads of developers still use MFC. OK - if you're writing a new project, MFC would not be a great choice. But what if you're maintaining a 1.5 million line MFC app?

MFC support in Visual Studio has barely improved since VC++ 6.0 - in fact its got worse. Their cursory attempt to show an effort by adding support for the Ribbon Control with the MFC feature pack was not enough. Why can we still not properly use tab controls in the dialog editor?

Those who use MFC are probably supporting big enterprise applications - for a long time now we've been neglected. Please vote for more MFC support in Visual Studio Uservoice below:

http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2782934-improve-mfc

Will they listen? Chances are not - unless lots of people vote. But I'd really like to see some effort on this, it's a technology still used by many.

It would be interesting to see a survey of enterprise applications - and what they're written in. It'd be interesting to then compare this to how well MS support that platform. MS will put lots of efforts into what they think that developers should be using - but how well are they supporting their real customers who are creating real products?

Could not load file or assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or one of its dependencies.

Mon, 16 Apr 2012 07:55:00 +0000

Are you getting the error below when working with Silverlight projects?

Could not load file or assembly 'System.Windows, Version=2.0.5.0, 
Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or
 one of its dependencies.

It's a bit of an odd one. The solution that works for me is to re-register System.Core and System.Windows in the GAC. Use the commands below.

32 Bit System

"C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\gacutil" /i "C:\Program Files\Microsoft Silverlight\4.1.10111.0\System.Core.dll"
"C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\gacutil" /i "C:\Program Files\Microsoft Silverlight\4.1.10111.0\System.Windows.dll"

64 Bit System

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\gacutil" /i "C:\Program Files\Microsoft Silverlight\4.1.10111.0\System.Core.dll"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\gacutil" /i "C:\Program Files\Microsoft Silverlight\4.1.10111.0\System.Windows.dll"

So far I am yet to understand why this happens - if anyone can shed any light please comment!

Embedding a Console in a C# application

Tue, 28 Feb 2012 05:29:00 +0000

I have uploaded a new article on the CodeProject - embedding a Console in a C# Application. Here's a screenshot of the control in use:

As always, comments and suggestions are more than welcome - you can find the article here: http://www.codeproject.com/Articles/335909/Embedding-a-Console-in-a-C-Application

SharpGL 2.0

Wed, 22 Feb 2012 03:42:00 +0000

SharpGL 2.0 has been released - hit the GitHub site to get it: https://github.com/dwmkerr/sharpgl

Some new features:

Full support for all OpenGL functions up to OpenGL 4.2
Full support for all commonly used OpenGL extensions
Support for WinForms applications
Support for WPF applications (without resorting to WinForms hosts)
A powerful scene graph including polygons, shaders, NURBs and more
Many sample applications as starting points for your own projects.
Visual Studio Extension with SharpGL project templates for WPF and WinForms.

And a few screenshots:

The Radial Blur Sample

The New Project Types

WPF Support

Text Rendering

Debugger:: An unhandled non-continuable exception was thrown during process load

Wed, 08 Feb 2012 06:54:00 +0000

The following exception can be a very tricky one to deal with:

Debugger:: An unhandled non-continuable exception was thrown during process load

here's some tips if you get it.

Are you linking to winmm.lib? If so avoid it - it can cause these problems.
Are you delay-loading the module? If not, try it - this can often resolve this issue if other modules like winmm.lib are interfering with the module that causes this exception.
Are you using C++/CLI for the excepting module? If so, try using #pragma pack around exported class definitions.

If you haven't specified packing - do so. This is good practice anyway. I've used libraries that change the packing (which is very bad behaviour) before and this has caused all sorts of problems, so try and do the following:

// Push packing options, specify the packing.
#pragma pack(push, 1)
// Exported class
class MY_API MyClass
{
public:
// ...etc

};

// Restore packing options.
#pragma pack(pop)

Switch

Sat, 04 Feb 2012 03:53:00 +0000

I have written the second article in my series on Extending Visual Studio. In this article I describe how to create a Visual Studio Addin that allows you to switch between cpp/h files, WinForms code and designer, XAML and codebehind and so on. You can find the article on the CodeProject here:

http://www.codeproject.com/Articles/324611/Extending-Visual-Studio-Part-2-Creating-Addins

There is also a direct download page on this blog, you can get Switch from dwmkerr.com by going here:

http://www.dwmkerr.com/page/Switch.aspx

Funky WPF - Enumerations and the Combo Box

Wed, 18 Jan 2012 03:11:00 +0000

Binding a combo box to an enumeration in WPF is more work than it should be, creating an object data provider etc etc:

<Window.Resources>
<ObjectDataProvider MethodName="GetValues"
ObjectType="{x:Type sys:Enum}"
x:Key="CharacterEnumValues">
<ObjectDataProvider.MethodParameters>
<x:Type TypeName="Character" />
</ObjectDataProvider.MethodParameters>
</ObjectDataProvider>
</Window.Resources>

Followed by

<ComboBox SelectedItem="{Binding Character}"
 ItemsSource="{Binding 
Source={StaticResource CharacterValues}} "/>

What a pain! I have just added 'EnumerationComboBox' to my Apex library - so now you can do this:

<!-- The combo box, bound to an enumeration. -->
<apexControls:EnumerationComboBox 
SelectedEnumeration="{Binding Character}" />

No need for an ObjectDataProvider, an items source or anything – and if you decorate enum’s with the ‘[Description]’ attribute, it’ll use the description in the combo.

There’s an article/download here for anyone who's interested:

http://www.codeproject.com/KB/WPF/enumcombobox.aspx

Apex 1.2 Released

Tue, 01 Nov 2011 07:31:00 +0000

Apex 1.2 has been released, with some new features:

The ‘Compatibility’ namespace, which contains classes to address compatibility issues between WPF, Silverlight and WP7.
The ‘Asynchronous Command’ object, which provides a powerful way to use Asynchronous Commands in MVVM.

The release is at: https://github.com/dwmkerr/apex

MVVM Commanding

Sat, 29 Oct 2011 08:31:00 +0000

I have written an article that describes commanding in WPF, Silverlight and WP7 in detail. It is on the CodeProject at:

http://www.codeproject.com/KB/WPF/consistentmvvmcommands.aspx

It uses the latest version of Apex (version 1.2) which will be released formally shortly. Enjoy!

MVVM: Asynchronous Commands

Mon, 24 Oct 2011 03:51:00 +0000

The latest cut of the Apex Code (http://apex.codeplex.com/SourceControl/changeset/changes/6701) contains a very cool new feature - Asynchronous Command Objects.

An Asynchronous Command is a ViewModelCommand - the standard object used in Apex for commanding. However, what is different about this function is that it runs Asynchronously.

One of the problems with running a view model command asynchronously is that generally the view model properties cannot be accessed - as they're created on a different dispatcher. This problem is resolved by using the 'ReportProgress' function. Here's an example:

public class SomeViewModel : ViewModel
{
public SomeViewModel()
{
// Create the command.
asyncCommand = new AsynchronousCommand(DoAsyncCommand, true);
}
private void DoAsyncCommand()
{
for(int i = 0; i < 100; i++)
{
// Perform some long operation.
string message = DoSomeLongOperation();
 // Add the message to the View Model - safely!
asyncCommand.ReportProgress(
() =&gt;
{
messages.Add(message);
}
);
}

}
private ObservableCollection<string> messages =
new ObservableCollection<string>();
public ObservableCollection<string> Messages
{
get { return messages; }
}
private AsynchronousCommand asyncCommand;
public AsynchronousCommand AsyncCommand
{
get { return asyncCommand; }
}
}

In this basic mock-up we have a command called 'AsyncCommand' (which we could bind a button to for example) which invokes DoAsyncCommand. However, it invokes it Asynchronously. We can also update the ViewModel properties by using ReportProgress - meaning AsyncCommands can seamlessly provide live feedback while they're working - and we're keeping well locked in with the MVVM commanding model!

Expect a full article soon on the CodeProject, until then the source is at:

http://apex.codeplex.com/SourceControl/changeset/changes/6701

CodeProject Competition

Thu, 06 Oct 2011 07:30:00 +0000

My Solitaire and Spider Solitaire in WPF article is in two CodeProject competitions this month. The article is at:

https://www.codeproject.com/Articles/252152/Solitaire-and-Spider-Solitaire-for-WPF

If you think the article is worthy of a vote, then please go to the voting page for either of the two competitions!

Best C# Article: http://www.codeproject.com/script/Surveys/VoteForm.aspx?srvid=1209

Best Overall Article: http://www.codeproject.com/script/Surveys/VoteForm.aspx?srvid=1212

Drawing a DIB Section in WPF

Fri, 30 Sep 2011 05:09:00 +0000

One of the most exciting new features in the forthcoming SharpGL 2.0 (which was actually planned for 2.1 but has been moved to 2.0) is the facility to do OpenGL drawing in a WPF control. This isn't done via a WinFormsHost (which has unpleasant side-effects due to Airspace, see http://msdn.microsoft.com/en-us/library/aa970688(v=VS.100).aspx) but actually via an Image in a WPF UserControl.

What does this mean? Well it means that when you use the SharpGL.WPF libraries OpenGLControl you get what is essentially a genuine WPF control - you can overlay other controls on top of it, with transparency and bitmap effects and do everything you'd normally be able to do with a WPF control.

How this works is an interesting bit of code so here are the details.

When using a WPF OpenGL control we render either using a DIBSectionRenderContextProvider, or a FBORenderContextProvider. Here's the difference:

DIBSectionRenderContextProvider - Renders directly to a DIB Section. Supported with any version of OpenGL but never hardware accelerated.

FBORenderContextProvider - Renders to a Framebuffer object, via the GL_EXT_framebuffer_object extension. This is fully hardware accelerated but only supported in OpenGL 1.3 and upwards. The resultant framebuffer is copied into a DIB section also.

With either render context provider we end up with a DIB section that contains the frame - here's how we can render it:

/// <summary>
/// Converts a <see cref="System.Drawing.Bitmap"/> into a WPF <see cref="BitmapSource"/>.
/// </summary>
/// <remarks>Uses GDI to do the conversion. Hence the call to the marshalled DeleteObject.
/// </remarks>
/// <param name="source">The source bitmap.</param>
/// <returns>A BitmapSource</returns>
public static BitmapSource HBitmapToBitmapSource(IntPtr hBitmap)
{
BitmapSource bitSrc = null;
try
{
bitSrc = System.Windows.Interop.Imaging.CreateBitmapSourceFromHBitmap(
hBitmap,
IntPtr.Zero,
Int32Rect.Empty,
BitmapSizeOptions.FromEmptyOptions());
}
catch (Win32Exception)
{
bitSrc = null;
}
finally
{
Win32.DeleteObject(hBitmap);
}
return bitSrc;

}

This function allows us to turn a handle to a DIB section into a BitmapSource. The OpenGLControl is essentially just an image, and with each frame we simply set the BitmapSource to the newly rendered DIBSection.

The version of the code this post relates to is: http://sharpgl.codeplex.com/SourceControl/changeset/view/4805

The WPF example renders the Utah Teapot (http://en.wikipedia.org/wiki/Utah_teapot) directly in a WPF application. We're still pre-beta but grab the code if you want to try OpenGL in WPF.

Importing OpenGL Extensions Functions with wglGetProcAddress

Sat, 24 Sep 2011 06:57:00 +0000

There are only a small set of the core OpenGL functions that can be imported via p/invoke - the majority of OpenGL functions are actually extension functions which are supported only on specific video cards. OpenGL offers a function called wglGetProcAddress which can return the address of a named function - but how do we deal with this in the managed world?

Here's a brief description of how it's handled in SharpGL. As of this morning, SharpGL's latest version contains all core functions up to OpenGL 4.2 and all standard extensions up to OpenGL 4.2. This takes the support for OpenGL to the latest version - August 2011.

First we must import the wglGetProcAddress function:

[DllImport("opengl32.dll")]
public static extern IntPtr wglGetProcAddress(string name);

This is the correect p/invoke method of importing this function, however it returns an IntPtr, which we cannot call as a function. We could change the return type to a delegate but this function can return essentially any type of delegate - so where do we go from here?

Well the next step is to define the delegates we want to use - they must have exactly the same name as the OpenGL functions and use the correct parameters for marshalling. Here are a couple of delegates for OpenGL 1.4:

private delegate void glBlendFuncSeparate (uint sfactorRGB, uint dfactorRGB, uint sfactorAlpha, uint dfactorAlpha);
private delegate void glMultiDrawArrays (uint mode, int[] first, int[] count, int primcount);

Now we must create a function which will turn an IntPtr into a delegate and invoke it:

/// <summary>
/// The set of extension functions.
/// </summary>
private Dictionary<string, Delegate> extensionFunctions = new Dictionary<string, Delegate>();
/// <summary>
/// Invokes an extension function.
/// </summary>
/// <typeparam name=“T”>The extension delegate type.</typeparam>
/// <param name=“args”>The arguments to the pass to the function.</param>
/// <returns>The return value of the extension function.</returns>
private object InvokeExtensionFunction<T>(params object[] args)
{
// Get the type of the extension function.
Type delegateType = typeof(T);
// Get the name of the extension function.
string name = delegateType.Name;
// Does the dictionary contain our extension function?
Delegate del = null;
if (extensionFunctions.ContainsKey(name) == false)
{
// We haven't loaded it yet. Load it now.
IntPtr proc = Win32.wglGetProcAddress(name);
if (proc == IntPtr.Zero)
throw new Exception("Extension function " + name + " not supported");
// Get the delegate for the function pointer.
del = Marshal.GetDelegateForFunctionPointer(proc, delegateType);
if (del == null)
throw new Exception("Extension function " + name + " not supported");
// Add to the dictionary.
extensionFunctions.Add(name, del);
}
// Get the delegate.
del = extensionFunctions[name];
// Try and invoke it.
object result = null;
try
{
result = del.DynamicInvoke(args);
}
catch
{
throw new Exception("Cannot invoke extension function " + name);
}
return result;

}

We now have a generalised way to invoke an extension function. The loaded functions are stored in a dictionary keyed by name so that the heavy lifting is only done the first time we try to invoke the function. We can finally add the functions to the class as below:

public void BlendFuncSeparate(uint sfactorRGB, uint dfactorRGB, uint sfactorAlpha, uint dfactorAlpha)
{
InvokeExtensionFunction<glBlendFuncSeparate>(sfactorRGB, dfactorRGB, sfactorAlpha, dfactorAlpha);
}
public void MultiDrawArrays(uint mode, int[] first, int[] count, int primcount)
{
InvokeExtensionFunction<glMultiDrawArrays>(mode, first, count, primcount);
}

This is pretty cool - we can invoke any extension function as long as we have defined a delegate for it. What's more, by making the InvokeExtensionFunction function public we can allow other developers to provide their own delegates and invoke other extension functions.

This is the technique used in SharpGL 2.0 to import extension functions - the Core/OpenGLExtensions.cs file contains thousands of lines of functions defined like this, however knowing how to invoke any kind of delegate is a useful skill in the managed world, so this trick could be used in other places.

The version of SharpGL this post relates to is at:

http://sharpgl.codeplex.com/SourceControl/changeset/view/4474

How ISupportInitialize Can Help

Sun, 18 Sep 2011 14:49:00 +0000

I have recently come to discover the ISupportInitialize interface and found that it is extremely useful when developing more complicated WinForms controls.

Here’s the link to the interface on MSDN: ISupportInitialize - here I’ll describe how it can be useful.

The Problem

I have a fairly complicated WinForms usercontrol called 'OpenGLControl', which allows OpenGL commands to be used to render 3D scenes in a C# WinForms application. The control has properties which are interdependent to each other. If these properties are set in the designer, code like this is generated:

// openGLControl1
// 
this.openGLControl1.Anchor = ((System.Windows.Forms.AnchorStyles)((((System.Windows.Forms.AnchorStyles.Top | System.Windows.Forms.AnchorStyles.Bottom)
 | System.Windows.Forms.AnchorStyles.Left)
 | System.Windows.Forms.AnchorStyles.Right)));
this.openGLControl1.BitDepth = 32;
this.openGLControl1.DrawRenderTime = true;
this.openGLControl1.FrameRate = 29.41176F;
this.openGLControl1.Location = new System.Drawing.Point(12, 12);
this.openGLControl1.Name = "openGLControl1";
this.openGLControl1.RenderContextType = SharpGL.RenderContextType.NativeWindow;
this.openGLControl1.Size = new System.Drawing.Size(768, 379);
this.openGLControl1.TabIndex = 0;
this.openGLControl1.OpenGLDraw += new System.Windows.Forms.PaintEventHandler(this.openGLControl1_OpenGLDraw);

Now this leads to a problem - BitDepth, OpenGLDraw, FrameRate etc must all be declared BEFORE the Size property is set - but how can we control this? Or how can we deal with this situation in general?

This is where the ISupportInitialize interface comes in. If a control is added to the design surface with this interface, we’ll get the following code wrapped around the designer code:

private void InitializeComponent()
{
 System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager(typeof(FormExample1));
 this.label1 = new System.Windows.Forms.Label();
 this.linkLabel1 = new System.Windows.Forms.LinkLabel();
 this.openGLControl1 = new SharpGL.OpenGLControl();
 ((System.ComponentModel.ISupportInitialize)(this.openGLControl1)).BeginInit();
 this.SuspendLayout();
 //
 // ...ordianry designer code...
 //
 ((System.ComponentModel.ISupportInitialize)(this.openGLControl1)).EndInit();
 this.ResumeLayout(false);
 this.PerformLayout();
}

Now just implement the ISupportInitialize interface in your control - in the ‘EndInit’ function do any processing that depends on the interdependent properties. This is the earliest point that we can do processing like this. In certain circumstances, knowing about this interface can save you a lot of trouble.

P/Invoke Performance

Mon, 12 Sep 2011 13:09:00 +0000

SharpGL 2.0 has no P/Invoke - all native functions are called by a C++/CLI class library (OpenGLWrapper if you're getting the code from CodePlex) which calls functions directly. This means there's no more importing of PIXELFORMAT structures and so on.

The thinking behind this was that a C++/CLI wrapper is faster than P/Invoke for a talkative API like OpenGL - but is this actually the case? In my new article on the CodeProject I investigate the performance differences between these two methods.

http://www.codeproject.com/KB/dotnet/pinvokeperformance.aspx

Trials and Tribulations with SharpGL 2.0

Mon, 12 Sep 2011 06:03:00 +0000

SharpGL has not been updated for a while, the original CoreProject article is at: http://www.codeproject.com/KB/openGL/sharpgl.aspx

Recently I have begun work on SharpGL 2.0, with plans to address some of the issues people have had with SharpGL 1.83. In preparation there is a public accessible repository on CodePlex: http://sharpgl.codeplex.com/ check it soon, it will shortly be online.

Trying to squeeze acceptible performance from SharpGL has so far been an interesting task, I have found out many interesting things on the way, I'll be posting small snippets as I work on SharpGL 2.0 describing how I'm improving the performance and structure of the library.

Solitaire and Spider Solitaire on the CodeProject

Mon, 12 Sep 2011 06:01:00 +0000

I have uploaded a new article on the CodeProject, a step by step tutorial showing how to create Solitaire and Spider Solitaire for WPF with the help of Apex.

The article is available at: http://www.codeproject.com/KB/WPF/solitaire.aspx