ILMerge and .NET 4.0 projects – Unresolved assembly reference not allowed…

February 16th, 2011 Comments off

For plugin development on an ASP.NET website (using  MEF), I am trying to use ILMerge to merge all .NET assemblies in one assembly. I used a blog post from Scott Hanselman on ILMerge for a starter, but although I followed every step in his post, I ran into the following exception: Unresolved assembly reference not allowed: System.<WhatSoEver>. After  a little investigation, I discovered that ILMerge by default does not understand how to merge projects using the .NET 4.0 framework.

Adding an ILMerge.exe.config file with the following piece of code in it solved my problems:

<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <requiredRuntime safemode="true" imageVersion="v4.0.30319" version="v4.0.30319"/>
  </startup>
</configuration>

This was able to successfully resolve my issue.

Categories: .NET, ilmerge, visual studio 2010

Threading in C# – complete reference

February 14th, 2011 Comments off

A colleague of mine just showed a great complete reference for threaded programming in C#. Since the article is great, I would like to share this one with the world. Here it is: http://www.albahari.com/threading/.

Cheers!

Categories: .NET, threading

Red-Gate’s Reflector to be paid for – free alternatives?

February 14th, 2011 4 comments

Hi folks,

I recently discoverd that by the end of February 2011 Red-Gate stops providing Reflector for free. Although their reason sounds obvious (they cannot work for free), I think many developers still rather prefer a free IL deassembler tool. Luckily, Scott Hanselman twittered about free open source alternatives. Those open source alternative IL deassembler projects are both based on the Mono Cecil project.

I would hereby like to share them with you:

Happy coding! Cheers!

PS. Of course I am very much interested in other free alternatives. Please post your comments if any Red Gates Reflector to be paid for free alternatives? icon wink …

UPDATE 04/27/2011: On Twitter I heard @dotnetreflector say to @haacked that they are releasing Reflector v6 with no expiry date for existing users in May 2011! http://bit.ly/eW3D7O.

Categories: .NET, disassembler, open source, reflection, visual studio 2010, wpf

WIX 3.5 – error LGHT0001: Unable to load DLL ‘winterop.dll’

August 25th, 2010 Comments off

It has been a while, but here I am again WIX 3.5 error LGHT0001: Unable to load DLL winterop.dll icon wink … I am currently working on an old Visual Studio 2005 solution. This bugger used to be built by a build server, but that one died about a year ago. Since some bugs really needed fixing, I decided that I would build the project myself for the moment.

Problem was that the solution uses WIX 3.0, and I have WIX 3.5 installed on my machine. After converting the WIX projects I expected the project to build without any problems. Unfortunately, however, WIX crashes with the following error: error LGHT0001: Unable to load DLL ‘winterop.dll’: The specified module could not be found. (Exception from HRESULT: 0x8007007E).

After some searching on the web I found a post (not entirely my problem) with the searched solution: add the installation path of WIX to the Path variable. After this workaround everything works like a charm. Hope this helps you too WIX 3.5 error LGHT0001: Unable to load DLL winterop.dll icon wink !

Happy coding!

Categories: .NET, bug, tip, visual studio, WIX

Setup project with COM library installation (Visual Studio)

March 18th, 2010 Comments off

Today at work I had a requirement on a setup that a certain COM library should be registered on application setup. Browsing the internet for a solution, I found the next information at MSDN (just copied here to prevent it from being lost Setup project with COM library installation (Visual Studio) icon smile ):

Steps to Register a COM Module in a Visual Studio .Net Deployment Project

  1. Add a COM object to your Visual Studio deployment project.
  2. In the Solution Explorer, right-click the module that you just added, and then click Properties.
    NOTE: The Properties window contains a table with two columns and x number of rows (the number of rows depends on the project). The left column lists the specific properties. The right column is explained in step 4.
  3. Go to Properties for this module (located by default in the upper-right corner of the .NET Deployment project), and then click Registry property.
    NOTE: The Registry property specifies whether a file, assembly, or project output group should be registered on a target computer during installation.
  4. There is a list box in the right column of the Registry property, which displays several options for you to choose from. Note the following details for an explanation of these options:
  • For assembly, registration is not normally required, and therefore the default is DoNotRegister (this means that the item will not be registered during the installation).
  • For a COM module, you have the options of COM, COMRelativePath, and COMSelfReg. Any one of those three options will register the COM module during the installation.

Note the following details about each choice:

  • COM: The module will be registered as a COM object by the Windows Installer engine. The deployment project will update the Class table, ProgID table, and other tables in the Registry Tables group of the corresponding .msi file. This is the recommended way to register a COM module.
  • COMRelativePath: The module will be registered as an isolated COM object by the Windows Installer engine. Note that this module will be used only by the application that the module is installed with.
  • COMSelfReg: The installer calls the DllRegisterServer function of that module at the time that you install the module and the DllUnregisterServer function at the time that you uninstall the module. The deployment project will update the SelfReg table of the corresponding .msi file. It is not recommended that the installation package use self-registration. Instead, the installation package should register modules by authoring one or more of the other tables provided by the installer for this purpose (that is, select the COM or COMRelativePath options). Many of the benefits of having a central installer service are lost with self-registration, because self-registration routines tend to hide critical configuration information.

You can now build your deployment project to allow the preceding modifications to register your COM objects in accordance with the registration property options that you selected in step 4.

Although it sounds frustrating, using this information, registering COM libraries at application setup is quite easy!

Happy coding!

Categories: installer, setup project, visual studio, visual studio 2005, visual studio 2008