Last week I have attended ITCamp in Cluj-Napoca, Romania. The conference has already established itself as the most important community-driven technology conference in Romania and lately, as the organizers put it, its focus has shifted from being a Microsoft-centric conference to a technology-centric conference. And this year it has been larger than ever before: 600 attendants, more than 40 speakers, more than 50 sessions and open panels grouped on 5 different tracks. A little bit for everybody. And with so many tracks and session it was a little bit hard to make choices for what to attend or maybe rather what to skip.

All sessions have been recorded and will be made available some time in the future (as far as I understood). In the meanwhile I wanted to point some of the things I seen and learnt at ITCamp. I actually attended more talks than the one mentioned here. Most of them were really good and I apologize to those not mentioned, but I don’t want to mention everything here, so I will try to summarize only a few things that I found the most interesting.

  • Security
    I have attended several talks on security. Paula Januszkiewicz gave all of us creeps by showing how a skillful person can extract information such as encrypted passwords and history information that the system stores on disk without most users being really aware of it. And even though the secrets are well kept for a regular user, a malicious person or software can exploit weaknesses to extract these information. On the other hand Jayson E. Street shared his experiences with compromising security in all sorts of companies around the world. Having a 100% success rate Jayson doesn’t blame it on the employees or users (explicitly saying there is no such thing as stupid user) but on the lack of education/training on security that companies are providing (or rather not providing) for their employees. His talks made us laugh but also think a lot and hopefully be more aware of things we shouldn’t do from the point of view of security. One thing for sure, I will never plugin a USB stick that I find on my desk in a blank envelope with my name on it. Thanks Jayson!

  • Internet of Things
    Who would have though several years ago that your greenhouse could be monitored and controlled from the internet? That it could send pictures to your phone? That you can make predictions on when and how much to sprinkle based on the existing data? That’s what Laurent Ellerbach, Microsoft Technical Evangelist Lead, shown in his keynote. Sensors, Raspberry PI, cameras, Azure IoT Hub, Stream Analytics, Mobile Services, SQL Azure and others working together to create a real world system for a sprinkler for his small greenhouse at home. It was a very interesting talk with a real life project and its development over time to include more and more services.
  • PowerShell is now an OOP language
    I am not very skilled with PowerShell, though I have to use it from time to time. I had no idea though that PowerShell 5 supports many features from object-oriented programming. These includes: classes, methods, properties, inheritance, enumerations and others. Razvan Rusu delivered an entertaining talk for both developers and sysadmins showing how easy you can do things in PowerShell and what the new OOP features are. It was really interesting and will certainly look at PowerShell from a different perspective from now on.
  • .NET core
    Raffaele Rialdi gave a compelling introduction to .NET core, its components, flavors, its new deployment mechanism based on NuGet and other related topics.
, , , , , , , Hits for this post: 6388 .

In WPF, Silverlight and Windows Phone it is possible to render a visual object into a bitmap using the RenderTargetBitmap. This functionality, that I find pretty basic, was not available for Windows Store applications. Fortunately, Windows 8.1 provides that functionality for Windows Store applications too, through the same RenderTargetBitmap class.

There are some limitations though:

  • it should be used in the code behind (not declared in XAML) because you have to call RenderAsync
  • collapsed visual objects are not rendered (only visible ones)
  • in rare circumstances the content can be lost due to the interaction with lower level systems; in this case a specific exception is triggered
  • the rendered target bitmap does not automatically scale when the current DPI settings change
  • the maximum rendered size of a XAML visual tree is restricted by the maximum dimensions of a DirectX texture

Here is a demo Windows Store application that has several controls and a button that when pressed a screenshot of the area shown in red (it’s a grid) is taken. The bitmap is saved on disk, but also displayed as the source for the image control shown in the preview area.


The handler for the Click button even looks like this:

SaveScreenshotAsync is an async method that takes the reference to the FrameworkElement to be rendered to a bitmap (in this case the constrolsGrid) and returns a Task<RenderedTargetBitmap> that can be awaited on. As soon as we have the bitmap we set it as the source for the image control (imagePreview).


SaveScreenshotAsync is an async method that takes the FrameworkElement to be rendered to a bitmap and returns a Task<RenderedTargetBitmap> that can be awaited on. This method first prompts the user to select a destination file for the rendered bitmap. When the file is available it calls SaveToFileAsync to rendered the bitmap and write it to the file.

SaveToFileAsync is an async method that takes the FrameworkElement to be rendered to a bitmap and the StorageFile when the bitmap is to be saved and returns a Task<RenderedTargetBitmap> that can be awaited on. The file is opened asynchronous for read-write access and the returned IRandomAccessStream is passed further together with the framework element and the bitmap encoder id (that specifies how the bitmap should be encoded, i.e. BMP, JPEG, PNG, GIF, etc.) to CaptureToStreamAsync.

CaptureToStreamAsync creates a new RenderTargetBitmap object and calls RenderAsync to render the visual tree of the framework element to a bitmap. After the bitmap is rendered it retries the image as a buffer of byes in the BGRA8 format. It then asynchronously creates a BitmapEncoder for the IRandomAccessStream stream that it received as an argument, it calls SetPixelData to set the pixels data (notice the BitmapPixelFormat.Bgra8 parameter that matches the pixels format returned by GetPixelsAsync) and later asynchronously flushes all the image data, basically writing it to the file. It then returns that RenderTargetBitmap object that it created, which is used eventually as the source for the image control.

Here is how the saved JPEG image (also seen in the preview screenshot above) looks likes:

You can check the source code of the attached WinRT Screenshot demo (1537). It requires Visual Studio 2013 and Windows 8.1.

, , , , , , Hits for this post: 39912 .

A WinForms DataGridView control has the ability to automatically generate its columns and populate from a specified data source (which can be a DataSet, a simple list or something else). All you have to do is something like this:

When you do the same in MFC, it doesn’t work (supposing that you followed all the steps for hosting a WinForms control in an MFC application as described in MSDN).


After debugging through the .NET framework sources I realized the problem was that the BindingContext property of the DataGridView control was null. This property represents a manager of the list of bindings for the control. If this is null then the control will use the binding context of the parent, which is usually a WinForms form. However, in this MFC application there is no WinForms form and the parent of the DataGridView control is null, which means the control does not have a bindings manager, and no bindings can be set.

The solution is to explicitly set the BindingsContext property to an existing binding context (a new object) before setting the data source.


The lesson learned is that when you host a WinForms control in an MFC application some things won’t just work out of the box, if they rely on a parent form functionality. There is no such WinForms form and you might need to do additional manual initialization.

, , , , , , Hits for this post: 38196 .


I have recently migrated a C# 2.0 project registered for COM interop to .NET 4.5 and when I imported the type library in a C++ project with no_registry, suddenly I got some errors because the type library could not be imported. Here are the steps to reproduce:

  • create a .NET Class Library project and set platform target to .NET framework 4.5
  • check Register for COM interop
  • build the project
  • import the type library in a C++ project:

The result is the following error:


Searching for the solution I found that this was a known issue when you have both CLR 2.0 and 4.0 installed on the same machine. See this KB article: VC++ 2010 #import with no_registry fails with error C1083 or C3510. Unfortunately I was unable to fix the problem with the solution indicated there.

There are two tools that can generate a type library from an assembly:

  • tlbexp.exe: generates a type library from a specified .NET assembly
  • regasm.exe: registers metadata from an assembly to the Windows Registry, but in addition can create a type library from for the input assembly when /tlb switch is used.

When a project specifies to register for COM interop what Visual Studio does is similar to calling regasm.exe with /codebase switch specified. Since I had before problems with interop assemblies automatically generated by Visual Studio (with tlbimp.exe) I though it would be the same (only the other way around). Therefore I unchecked “register for COM interop” and added as a custom build step registration with regasm.exe, like this:

Not very surprisingly, the generated file was different and the #import command executed without problems.

Problem solved!


The question that arises is why are the two files, generated with Visual Studio and with regasm.exe, different? You can see they are different if you open them in an hex editor. But if you just use oleview.exe, the disassembled type library looks identical.

The obvious answer that occurred to me, but eventually proved wrong, was that Visual Studio is not actually using regasm.exe to register the assembly and generate the type library. It actually uses a MSBuild task for that.

When the RegisterForComInterop property is set in a .csproj an MSBuild task is executed.

The task can be found in Microsoft.Common.targets (in c:\Windows\Microsoft.NET\Framework\v4.0.30319\)

To check if I can reproduce, I have created MSBuild file (explicitreg.xml) with some hard-coded values that only runs that registration task.

But surprise: this produced the exact same output as the regasm.exe command. Comparing the diagnose logs from MSBuild (for the build of the .csproj and my custom file) I couldn’t spot any difference in the execution of the task. Also using the Process Monitor (procmon.exe from Sysinternals) to check access to the TLB file, I could clearly see the difference for the file writing, because different lengths were produced from Visual Studio build and explicit MSBuild run, though again I could not see any difference in the call stacks.

So, the actual cause for this behavior is still unknown to me and I would appreciate if anyone that knows the answer clarifies it.

, , , , , , , Hits for this post: 47600 .

The Problem
You install a .NET redistributable package and want to reference the assemblies in your project. However, though everything is correctly installed to GAC, the assemblies don’t show up in Visual Studio’s Add Reference dialog in the .NET tab (regardless of what version of Visual Studio you have).

The Cause
Redistributable assemblies are intended for runtime. They are assemblies that have to be deployed on a target machine, so that applications needing them run correctly on other machines than the development machines. They are installed in GAC, but that is not enough for Visual Studio to pick them up and display them in the Add Reference dialog, in the .NET assemblies tab. Actually Visual Studio scans a set of folders that is specified in Registry and that’s why your redistributables are not showing up.

The Solution
The solution is fairly simple. Basically you have to do two things:

  • first, you should make a copy of the assemblies to another folder
  • second, you have to add that folder in Registry where Visual Studio keeps its list of folders with references. The path differs on 32-bit and 64-bit machines, but the details are specified in this article How to: Add or Remove References in Visual Studio.

I will demonstrate the fix using the ReportViewer redistributable assemblies. I have several versions of Visual Studio installed on my machine: 2008, 2010 and 2012. I also have three versions of the ReportViewer control 9.0 (2008), 10.0 (2010) and 11.0 (2012), but also installed the redistributables for version 8.0 (2005). However, only the first three appear in Add References dialog in Visual Studio.

Add References dialog

Yet, all versions are present in GAC:

ReportViewer in GAC

I noticed that all other versions are installed under C:\Program Files (x86)\Microsoft Visual Studio xx\ReportViewer (where xx is the version). Since I already had a folder with some files for Visual Studio 2005, I created another folder there called ReportViewer.

In Registry, I looked for the key where the other versions are specified.

I added a new key called Report Viewer 8, and set the default value to the path of the folder that I created.

After re-opening the Add References dialog (no need to restart Visual Studio), the new assemblies shown up.

, , , , Hits for this post: 31008 .

Windows Runtime, or shortly WinRT, is a new runtime (siting on top of the Windows kernel) that allows developers to write Metro style applications for Windows 8, using a variety of languages including C/C++, C#, VB.NET or JavaScript/HTML5. Microsoft has started rolling out information about Windows 8 and the new runtime at BUILD.


WinRT is a native layer (written in C++ and being COM-based) that is intended as a replacement, or alternative, to Win32, and enables development of “immersive” applications, using the Metro style. Its API is object oriented and can be consumed both from native or managed languages, as well as JavaScript. At the same time the old Win32 applications will continue to run just as before and you can still (and most certainly will) develop Win32 applications.

Microsoft has created a new language called C++ Component Extension, or simply C++/CX. While the syntax is very similar to C++/CLI, the language is not managed, it’s still native. WinRT components built in C++/CX do not compile to managed code, but to 100% native code. A good news for C++ developers is that they can use XAML now to build the UI for immersive applications. However, this is not available for classical, Win32 applications.

You can get a glimpse of the new system and the tools by downloading and installing the Windows Developer Preview with tools, that includes the following:

  • 64-bit Windows Developer Preview
  • Windows SDK for Metro style apps
  • Microsoft Visual Studio 11 Express for Windows Developer Preview
  • Microsoft Expression Blend 5 Developer Preview
  • 28 Metro style apps including the BUILD Conference app

Notice this is a pre-beta release and you might encounter various problems.

Before you start here are several additional articles that you might want to read:

There are also several new forums available on MSDN forums for developing Metro style applications, which you can use for addressing technical questions. Hopefully thee will be answers from Microsoft people working in this area.

, , , , , , , , , Hits for this post: 68433 .

I’m using Red Gate’s .NET Reflector for decompiling .NET assemblies. It’s a great tool but it lacks, at least in the free version I’m using, information about the platform architecture of an assembly. Sometimes I want to know whether an assembly was built for Any CPU, x86 or x64.

The tool that help you find this information is CorFlags.exe from Windows SDK. It displays or configures the corflags section of a PE image. Here is an example of the output of corflags.exe:

The platform architecture is encoded in a combination of the PE and 32BIT flags:

  • Any CPU: PE=PE32 and 32BIT=0
  • x86: PE=PE32 and 32BIT=1
  • 64-bit: PE=PE32+ and 32BIT=0

So for the example above, PE is PE32 and 32BIT is 0, thus the platform architecture is Any CPU.

You can read more about this tool on Gaurav Seth’s blog.

, , , Hits for this post: 31575 .

I recently found a piece of code that can be summarized by the following sample:

As you can see there is an interface I that has two methods, F1 and F2. A is derived from X, that has a method F2, and also implements I, but only contains F1. I was puzzled at first, because I was expecting that A was explictitly implementing all the methods defined in the interface I. But F2 was implemented in X, its base class. After thinking a little bit it all become clear. This was a normal behavior of the compiler.

When a class A implements an interface I it guarantees that it supports (implements) the entire contract that the interface defines. But it does not assert that it will explicitly implement all the interface members within its explicit definition. I’m stressing on the explicit word here, because A extends (is derived from) X. That means A is an X. Everything that X exposes (i.e. what is visible to its derived classes) is part of A too.

In our case, F2, implemented in X, is also available to A, because A is an X. Since both F1 and F2 are members of A, then it means A fully implements I, which makes the code compile just fine.

How is this helpful? Suppose you have several interfaces that all define one ore several members with the same meaning.

Instead of providing the same implementation several times, like in the following code, you can have only one implementation for the common functionality.

We can create one class that provides the implementation for ErrorCode and let the others extend it and implement the corresponding interface.

, , , Hits for this post: 28075 .

DotNetZip Library

.NET 3.0 provides some support for working with ZIP files. However, it has an important drawback: it only works for packages that are conformant to the Open Packaging Convention standard. Most of the ZIP files are not. Codeplex features a library called DotNetZip that provides support for packing and unpacking in C#, VB.NET or any other .NET language, but also any COM environment, including Javascript, VBSCript, VB6, VBA, PHP, Perl. In addition to the basic packing and unpacking operations, it supports password protection, UNICODE filenames, ZIP64 and AES encryption, comment, and others. Here are some simple samples.

Creating a ZIP file:

Unpacking to a target folder:

Display the content of a ZIP archive:

You can find many more examples on Codeplex: C# and VB.NET.

, , , , Hits for this post: 33137 .

When you create a WPF application, the start-up window is by default one from the same project (by default called Window1.xaml).

But what if you want to use a window from another project (class library)? The pack URI scheme, used by WPF, allows you to identify and load files from:

  • the current assembly
  • a referenced assembly
  • a location relative to an assembly
  • the site of origin for the application

The format of the pack URI is pack://authority/path. The authority identifies the type of package and the path the location of a part inside a package. There are two authorities supported by WPF:

  • application:/// identifies application data files (known at compile time)
  • siteoforigin:/// identifies site of origin files

To use resource files from a referenced assembly you need to use the application:/// authority, and the path must have the form AssemblyShortName[;Version][;PublicKey];component/Path. Version and PublicKey are optional.

Let’s say you want to use a XAML called SampleWindow.xaml from a referenced assembly called WpfDemoLib. The App.xaml file should look like this:

You can learn more about pack URIs in WPF from MSDN.

, , , , Hits for this post: 47534 .