Pedram Rezaei's Ramblings : .NET

Introducing Parallel Extensions to the .NET Framework

pedramr — Wed, 06 Aug 2008 23:35:00 GMT

There is no escaping from concurrency challenges... or is there?

(A slightly modified version of this article was published in the August 2008 edition of the MSDN Flash newsletter)

Dual, quad, and eight-core processors are becoming the norm. Is your application capable of utilising all available processors? In order to achieve this level of utilisation on an n-processor machine, an application ideally needs at least n threads concurrently performing operations.

Although writing multi-threaded applications has become simpler over the years, many still find it challenging. Also many of the constructs such as the .NET ThreadPool have deficiencies that make them less suitable as the manycore shift begins to accelerate.

Over the past few years, Microsoft has been hard at work developing a new set of parallel extensions for .NET, aptly named Parallel Extensions to the .NET Framework. One of the additions is a set of lightweight and scalable thread-safe data structures and synchronization primitives such as a concurrent dictionary and a spin lock.

It also includes an implementation of LINQ-to-Objects that automatically executes queries in parallel, scaling to utilise most or all of the available processors without developers explicitly managing the distribution of work across all processors. This technology is called Parallel LINQ or PLINQ and the query syntax is almost identical to that of LINQ-to-Objects.

var q = from c in customers.AsParallel()

join r in regions on c.RegionID equals r.RegionID

where c.City == "London" && r.Name == "Kingston"

select c;

When a repetitive computation can be parallelised, the Parallel Extensions to the .NET Framework offers a few interesting data-oriented operations such as For and ForEach that execute a loop in which iterations may run in parallel on parallel hardware. For example the following classic foreach loop can easily be converted to a parallel foreach:

Sequential execution

foreach (var c in formulae)

Calculate(f);

Possible parallel execution

Parallel.ForEach(formulae, f => Calculate(f));

The actual parallelisation of actions is managed by the Task Parallel Library (TPL) that provides an abstraction layer on top of raw threads. TPL uses the notion of Task that is the smallest unit of work and could potentially be executed by any thread owned by TPL. Therefore correctly identifying tasks that could be executed in parallel is crucial. It is then the job of the scheduler component of TPL to decide whether those tasks should execute sequentially or in parallel. This decision is usually made based on available system resources and possible user preferences.

// Create a task to call Calculate(object o) and schedule it for execution

Task t = Task.Create(Calculate);

// Other activities...

// Wait for this task to complete

t.Wait();

Developing concurrent applications requires a shift in mindset. For example, only a single exception can be thrown at any one time when sequentially executing a for loop. However executing the same loop in parallel may warrant the need for dealing with multiple concurrent exceptions. There are also a few parallelism blockers that should be avoided if you are planning to benefit from Parallel Extensions to the .NET Framework when it is released.

There is a lot of promise in Parallel Extensions. If you want to find out more, I’d encourage you to download the June 2008 Community Technology Preview build.

ADO.NET Data Services: CLR-based data models and navigation links

pedramr — Sun, 20 Jul 2008 03:45:00 GMT

As you are probably aware, one of the new additions to the .NET Framework 3.5 SP1 is a technology called ADO.NET Data Services (code name Astoria). ADO.NET Data Services natively supports ADO.NET Entity Framework (EF) models. However Data Services it is not limited to EF.

ADO.NET Data Services can deploy consistent representations of data regardless of the underlying data source. This approach has made CLR-based data models first class citizens. See here for a comprehensive guide on using CRL-based data models.

Imagine the following class diagram that represents two entities:

As you can see, Library has a collection of Books. Therefore Library.Books can be considered a one-to-many resource navigation link to a collection of Books.

public class Library

{

public int LibraryID { get; set; }

public string LibraryName { get; set; }

public List<Book> Books { get; set; }

}

public class Book

{

public int BookID { get; set; }

public string BookTitle { get; set; }

}

A simple Data Services’ resource container exposing a list of libraries may look similar to the following:

public class LibraryDataModel

{

static List<Library> s_libraries = ...;

public IQueryable<Library> Libraries

{

get

{

return s_libraries.AsQueryable();

}

Unfortunatly exploring this data model – by perhaps browsing to the URI that exposes this model – may fail throwing an exception similar to the following:

Request Error: The server encountered an error processing the request. The exception message is 'The property 'Books' on type 'AstoriaWeb.Library' is not a valid property. Properties whose types are collection of primitives or complex types are not supported.'

This means that ADO.NET Data Services was not able to automatically consider Books as a resource set that can be referenced using resource navigation links from Library resources. In fact, without some more information, it is really hard for Data Services to automatically expose a new resource set through a resource container.

So how can you avoid this? For this release of Data Services at least, you need to explicitly expose Books as a resource set in the resource container:

public class LibraryDataModel

{

static List<Library> s_libraries = ...;

static List<Book> s_books = ...;

public IQueryable<Library> Libraries

{

get

{

return s_libraries.AsQueryable();

}

public IQueryable<Book> Books

{

get

{

return s_books.AsQueryable();

}

This article was written based on .NET Framework 3.5 SP1 Beta.

.NET debugging made easier

pedramr — Sun, 20 Jul 2008 02:34:00 GMT

Not sure about you but I was not aware of the existence of the DebuggerStepThroughAttribute. Debugging code can be difficult at times and any tool or mechanism that can ease this pain is always welcome.

As far as the CLR is concerned, there is no semantic attached to this attribute. However Visual Studio does not step through methods or classes that are decorated with this attribute. Although you could still use breakpoints in those methods or classes, they are never hit.

And here is how breakpoints would look in Visual Studio 2008:

This attribute can be applied to methods, property accessors, classes and structs. I found it to be extremely useful when I wanted to step through a method without first stepping through all property accessors used as parameters or the source instance of the method. In the example below, a.Value and b.Value are not stepped through when pressing F11 in Visual Studio. It is only the Add method that is fully debugged:

var a = new SomeValue(10);

var b = new SomeValue(150);

...

Add(a.Value, a.Value);

class SomeValue

{

...

public int Value

{

[DebuggerStepThrough]

get { return value; }

}

Enjoy!

System.Core.dll of .NET Framework 3.5

pedramr — Wed, 07 Nov 2007 14:20:00 GMT

I recently wrote an MSDN Flash article on the hidden gems of System.Core.dll of .NET Framework 3.5 which was published in the October issue of the MSDN Flash. Here is a copy of that article:

If you have played with Visual Studio 2008, chances are that you have come across the System.Core.dll which is automatically referenced when you create any new project that targets .NET Framework v3.5. Browsing through this new DLL using the Object Browser in Visual Studio, it soon becomes apparent that it is the home of many new namespaces, including the implementation of LINQ to in-memory objects. In this short article I offer an overview of the other APIs in this new assembly:

TimeZoneInfo class: This class represents a geographical time zone. It extends and supersedes the limited functionally offered by the TimeZone class by allowing you to represent any time zone. It also allows you to easily convert between time zones, retrieve an existing time zone or create a new one, and serialize to a string and reconstruct it back from a string.

HashSet<T> class: This class is a member of System.Collections.Generic namespace and provides very fast hash-based SET operations. A set is a collection of entities that includes no duplicates and is in no particular order. Internally items are stored in an array which includes the value, the hash code associated to the value, and the index of the next element in the bucket associated with this hash code. Having a link to the next element in the bucket, makes it extremely efficient to detect duplicate items when new items are inserted. Over and above the usual Add, Remove and Contains methods, HashSet also provides set operations such as union, intersection, and symmetric difference. For more information see this blog entry.

Pipes: .NET Framework 3.5 provides managed support for Pipes in Windows. Pipes are used for inter-process communication (IPC) between processes running on the same machine, or processes running on any other Windows machine within a network. You can find the classes related to this under the System.IO.Pipes namespace and remember that both Anonymous Pipes and Named Pipes are supported. For more information and a sample see this blog post.

ReaderWriterLockSlim class: If you have ever used the System.Threading.ReaderWriterLock to achieve synchronised access to shared resources which are frequently read but infrequently updated then you probably know why we have created a new Reader/Write lock. The performance of ReaderWriterLockSlim is roughly equal to that of Monitor and in some scenarios it is more scalable than its predecessor. It supports Read, Write and UpgradeableRead lock modes and it gives priority to write requests over reads. For more information see this blog.

Other: System.Core.dll offers managed wrappers to native APIs such as the Event Tracing for Windows (ETW), Performance Counters in Windows Vista and the Next Generation of Cryptography (CNG). Exploring those namespaces is left as an exercise for the reader.

System.Core.dll is only one of the many new assemblies that are part of .NET Framework v3.5. Now is a great time to get ahead of the rest and evaluate Visual Studio 2008.

A Performance Comparison of ReaderWriterLockSlim with ReaderWriterLock

pedramr — Sun, 07 Oct 2007 21:11:00 GMT

If you have ever used the System.Threading.ReaderWriterLock to achieve synchronised access to shared resources which are frequently read but infrequently updated then you probably know why we have created a new Reader/Write lock. In this MSDN Magazine’s concurrent affairs column, Jeffery Richter explains some of the short comings of the existing ReaderWriterLock in .NET Framework.

One of the hidden gems of the new .NET Framework 3.5 is a fast Reader/Writer lock called “ReaderWriterLockSlim”. If you are not familiar with this new lock then read this blog entry.

Before recommending this new lock to my customers, I wanted to see some comparisons with Monitor and the existing ReaderWriterLock. So, I devised the following comparison tests:

- Acquiring a Read lock in comparison with taking a lock using Monitor

- Acquiring a Write lock in comparison with taking a lock using Monitor

- Acquiring a Read/Write lock in comparison with taking a Read/Write lock using ReaderWriterLock

Read lock comparison with Monitor

After executing the test for 1000 times, it became apparent that ReaderWriterLockSlim with no recursion support is 1.67 times slower than Monitor and it is 1.74 times slower when recursion is supported:

Write lock comparison with Monitor

ReaderWriterLockSlim, in average, is 1.71 times slower than Monitor, and when recursion is supported it is 1.77 times slower.

It also turns out that acquiring a Read lock using the new slim lock class is slightly quicker than taking a Write lock.

ReaderWriterLockSlim in comparison with ReaderWriterLock

ReaderWriterLock is significantly slower than its successor:

- Taking a ReaderWriterLockSlim Read lock is almost 3 times quicker than ReaderWriterLock

- Taking a ReaderWriterLockSlim Write lock is 2.8 times quicker than ReaderWriterLock

Results at a glance:

The table below compares both Reader/Writer locks with Monitor:

	Monitor	ReaderWriterLock	ReaderWriterLockSlim (No recursion support)	ReaderWriterLockSlim (recursion support)
Read	1	5	1.67	1.74
Write	1	4.71	1.71	1.77

The above comparison was performed on a Toshiba M400 with a Centrino Duo processor using Visual Studio 2008 beta 2.

ThreadAbortException and Unmanaged Code

pedramr — Tue, 02 Oct 2007 15:04:00 GMT

As you are probably aware Thread.Abort() raises a ThreadAbortException in the thread on which it is invoked, to begin the process of terminating the thread.

Please note that if Abort is called on a managed thread while it is executing unmanaged code, a ThreadAbortException is not thrown until the thread returns to managed code. That is also true when performing a COM Interop or P-Invoke. However if you have a ServicedComponent, the exception is received by the thread inside the component as expected. For instance if you are in an ASP.NET application and a timeout is occurred (timeout is communicated in terms of a ThreadAbortException) the exception is raised inside the component.

.NET ServicedComponents and STA Apartment

pedramr — Sun, 05 Aug 2007 17:52:00 GMT

A major issue with running all COM components using STA threads is that the thread which calls CoInitializeEx must be the only thread executing method invocations on that COM instance. Now assume a scenario in which the STA thread is busy performing other activities. In those scenarios you will receive an exception similar to the following and the way around that is to somehow ensure that the message loop on the STA thread is being pumped frequently. In other words anything causing a delay in this process may be an issue and you may receive an exception similar to the following:

“ContextSwitchDeadlock was detected

The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.”

Here is an example of the problem (ComInstance is a ServicedComponent):

Thread t = new Thread(

delegate(object a)

{

ComInstance o = new ComInstance();

Thread tt = new Thread(

delegate(object q)

{

// A deadlock will be detected here
o.ComMethodCall();

});

tt.Start();

while (true)

{

// keep the thread alive

// must pump the message loop

// ...

}

});

t.SetApartmentState(ApartmentState.STA);

t.Start();
Console.ReadLine();

Dedicated thread or a Threadpool thread?

pedramr — Sun, 05 Aug 2007 17:48:00 GMT

Each .NET CLR based process is given a pool of threads. The size of the thread pool is configurable however by default the maximum number of threads created by the thread pool is set to 1000 IO threads in total, and 25 worker threads per logical or physical processor. In other words, when using a dual core processor, you will have the maximum value set to 50 worker threads.

These threads are managed in a very efficient and intelligent manner by the runtime. For instance, the actual size of the thread pool varies based on how the application is consuming those threads. It is possible to set the minimum number of threads for the thread pool. Once that many threads are created, they are kept alive for the lifetime of the process. However if more threads are required, the thread pool creates new threads. Once those threads finish executing their activities, they are then returned to the thread pool. It is important to emphasise that those threads are not destroyed. They will self destroy after approximately 2 minutes of inactivity. Therefore, the usage of system resources is constantly being adjusted automatically by the thread pool itself.

Once the minimum number of threads is reached, the thread pool aims to limit the number of threads being created to one per 500 milliseconds. This is an intelligent mechanism, avoiding the expensive cost of creating a new thread when multiple thread pool threads may be released within that time period.

The combination of the above approaches makes .NET’s thread pool a very intelligent thread pool which uses as little resources as possible to give maximum performance. Therefore in most scenarios it is recommended to use this thread pool for performing asynchronous operations.

.NET’s thread pool has some shortcomings which can affect the choice between using a dedicated thread instead of a thread from the thread pool. It is usually said that a dedicated thread is favourable in the following scenarios:

- When a foreground thread is required: All thread pool threads are initialised as background threads.

- When it is required to have a thread with a particular priority.

- When a thread is required to be aborted prematurely

- When a thread must be placed in a single-threaded apartment (STA): All thread pool threads are set in the MTA apartment by default

- For long running tasks when the thread pool thread is often blocked for long periods (This may starve other parts of the application which rely on threads from the thread pool)

The thread pool is shared by all AppDomains in a process. Consider this if you have more than one AppDomain in your process.

Automated build of Satellite Assemblies in Visual Studio with MSBUILD

pedramr — Sun, 05 Aug 2007 00:09:00 GMT

Download sample code

Much has been said and written about satellite assemblies and localization techniques that are achieved using them. I believe that most of the industry has no doubt in the usefulness of this amazing feature of the .NET Framework; however the lack of automation has made it slightly difficult for many companies to adopt. (In Visual Studio 2005 the generation of satellite assemblies for controls placed on Windows Forms is an automated process. Just use the localized property in conjunction with the language property of Forms. This is not covered in this blog entry).

Just to demonstrate how simple it is to automate the creation and build of these assemblies, I have put together a simple application which uses MSBUILD and post-build events to automatically generate resources and link them into satellite assemblies.

With satellite assemblies, they need to be placed in a specific directory structure. See http://msdn2.microsoft.com/en-us/library/21a15yht(vs.80).aspx for more information on this structure.

The first step in creating a satellite assembly is to compile .resx files into .resources files. This is usually done using the RESGEN utility or the GenerateResource MSBUILD task:

Resgen.exe /compile SatelliteAssembly.en-GB.resx,SatelliteAssembly.en-GB.resources

The second step is to use the assembly linker utility to create the satellite assembly from .resources files:

AL.exe /culture:en-GB /out:en-GB\SatelliteAssembly.resources.dll /version:1.0.0.0 /embed:SatelliteAssembly.en-GB.resources

<AL OutputAssembly="%(Culture)\SatelliteAssembly.resources.dll"

Version="1.0.0.0"

Culture="%(Culture)"

EmbedResources="@(Resources)"/>

The MSBUILD script is called by the post-build event of the executable project and here is what it does:

- MSBUILD script is executed by the post-build event of the executable project passing the path to the output directory

- .resx files are compiled into .resources

- .resources are linked into satellite assemblies

- Satellite assemblies are copied to the output folder

- All temporary files and folders are deleted

XML Configuration for .NET Applications

pedramr — Sat, 04 Aug 2007 00:27:00 GMT

There are at least 2 options to consider for using user-specific configurations:

- Custom configuration mechanism: using technologies such as the XML Serializer.

- XML Configuration feature in .NET 2.0: This is the main topic of this blog entry.

One of the great features of .NET Framework (first appearing in V2.0) has been its XML configuration feature. It allows applications to load configuration settings which are stored in XML configuration files. The structure of these can be hierarchical allowing a developer to specify different config files at machine, executable, roaming user and user levels. The framework then automatically merges the settings if required.

The hierarchical structure is slightly different for web based applications. I will concentrate mainly on the executable context (not web applications). The diagram below shows the configuration hierarchy for the executable context:

The machine level configuration applies to all applications that run within CLR. It is also used by the .NET Framework itself for its configuration needs.

Each configuration level shown in this diagram is more specific than its parent and can override the settings defined higher up in the hierarchy. For instance a setting defined in Machine.config can be overridden by defining the same setting in User.config.

By default the configuration files are defined in the following paths:

Machine level config:
%SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\CONFIG

Application level config: \[AppPath]\[ExeName].exe.config

Roaming user level config:
Windows XP:
C:\Documents and Settings\[User] \Application Data\[AppName]\[CodedPath]\[Version]\User.config
Windows Vista:
C:\Users\[User]\AppData\Roaming\[AppName]\[Vendor]\[CodedPath]\[Version]\User.config

User level config:
Windows XP:
C:\Documents and Settings\[User]\Local Settings\Application Data\[AppName]\[CodedPath]\[Version]\User.config
Windows Vista:
C:\Users\[User]\AppData\Local\[AppName]\[Vendor]\[CodedPath]\[Version]\User.config

The user level config is mainly associated to the profile of the logged on user and it makes it unsuitable for applications that require a different logon process. To accommodate for this type of scenario, it is possible to load different config files at each level of the hierarchy. This is done through the concept of “Configuration File Mapping”:

The ConfigurationManager class has 2 static methods which allow specific paths to .config files to be specified. These methods also automatically merge the config settings:

- OpenMappedMachineConfiguration

- OpenMappedExeConfiguration

When OpenMappedExeConfiguration is called, it requires an instance of the ExeConfigurationFileMap which allows you to specify exact paths to machine, executable, roaming user and local user config files..

The sample below demonstrates how to load a specific local user configuration file:

Debug.WriteLine(((CustomSection)ConfigurationManager.GetSection("CustomSection")).Text);

ExeConfigurationFileMap exeMap = new ExeConfigurationFileMap();

exeMap.ExeConfigFilename = "ConfigFileSample.exe.config";

exeMap.RoamingUserConfigFilename = "MyAppRoamingUser.config";

exeMap.LocalUserConfigFilename = "MyAppUser.config";

Configuration localUserConfig =

ConfigurationManager.OpenMappedExeConfiguration(

exeMap, ConfigurationUserLevel.PerUserRoamingAndLocal);

Console.WriteLine("Local user config path: " + localUserConfig.FilePath);

Debug.WriteLine(((CustomSection)localUserConfig.GetSection("CustomSection")).Text);

Debug.WriteLine(((CustomSection)ConfigurationManager.GetSection("CustomSection")).Text);

App.Config:

<section name="CustomSection"

type="ConfigFileSample.CustomSection, ConfigFileSample"

allowDefinition="Everywhere"

allowExeDefinition="MachineToLocalUser"

restartOnExternalChanges="true" />

</configSections>

</configuration>

MyAppUser.config:

</configuration>

Output:

Hello from app.config

Hello from MyAppUser

Hello from app.config

See here for more information on how to load custom configurations.

With the XML Configuration capabilities of .NET 2.0, it is also possible to create custom configuration sections. The framework itself automatically takes care of XML parsing, validation, security and the population of the .NET object representing the custom configuration section. Here is a very simple custom configuration section:

// Define a custom section.

public sealed class CustomSection : ConfigurationSection

{

// The collection (property bag) that conatains

// the section properties.

private static ConfigurationPropertyCollection _properties;

// Internal flag to disable property setting.

private static bool _readOnly;

// The FileName property.

private static readonly ConfigurationProperty _text =

new ConfigurationProperty("text",

typeof(string), string.Empty,

ConfigurationPropertyOptions.IsRequired);

// CustomSection constructor.

public CustomSection()

{

_properties = new ConfigurationPropertyCollection();

_properties.Add(_text);

}

// This is a key customisation.

// It returns the initialised property bag.

protected override ConfigurationPropertyCollection Properties

{

get { return _properties; }

}

private new bool IsReadOnly

{

get { return _readOnly; }

}

// Use this to disable property setting.

private void ThrowIfReadOnly(string propertyName)

{

if (IsReadOnly)

throw new ConfigurationErrorsException(

"The property " + propertyName + " is read only.");

}

// Customizes the use of CustomSection by setting _readOnly to false.

// Remember you must use it along with ThrowIfReadOnly.

protected override object GetRuntimeObject()

{

_readOnly = true;

return base.GetRuntimeObject();

}

[StringValidator(InvalidCharacters = " ~!@#$%^&*()[]{}/;'\"|\\",

MinLength = 1, MaxLength = 60)]

public string Text

{

get { return (string)this["text"]; }

set

{

ThrowIfReadOnly("Text");

this["text"] = value;

}

See http://www.codeproject.com/dotnet/mysteriesofconfiguration.asp and http://msdn2.microsoft.com/en-us/library/system.configuration.configurationsection(VS.80).aspx for more information on how to create custom sections and collections of these selections and elements.

Why use .NET 2.0 XML Configuration?

- Automatic inheritance and merge capabilities which allow developers to define common settings at higher levels of the hierarchy and override those if needed at lower levels.

- It is easily extendable using custom configuration settings and elements

- .NET 2.0 provides parsing, validation, security and population of the object model associated to the Configuration feature. For example it is possible to create a configuration section and validate its properties using Custom Attributes.

- Reuse of existing functionality

There is a lot more to be said about XML Configuration capabilities of .NET. However the objectives of this blog entry were to demonstrate how to load custom configuration files and to be an introduction to custom configuration sections.

Use of string.Format for the purpose of tracing

pedramr — Mon, 15 Jan 2007 15:06:00 GMT

Application tracing is usually turned off on production releases. Therefore it is recommended not to use string formatting methods if their output is being ignored. string.Format is usually an expensive method and should be avoided if its output is not consumed:

Log.Write(string.Format("User {0} tried to log on at {1}", userName, logonTime));

Many tracing and logging libraries provide methods which accept a format string and an array of objects. If tracing is enabled these parameters are used to call the string.Format method:

void WriteLine(string format, params object[] args)

{

if (IsTraceEnabled)

{

string formatedString = string.Format(format, ...

}

Non-CLS Exceptions

pedramr — Sun, 07 Jan 2007 16:56:00 GMT

Many developers are not aware that according to CLR it is perfectly OK to throw exceptions which are NOT derived from System.Exception: Exceptions such as DateTime, Int64 and String. Although languages such as C# do not allows programmers to throw these types of exceptions it should still be possible to catch non-CLS compliant exceptions using a catch block.

Pre to CLR version 2.0, the only way to catch non-CLS compliant exceptions was to introduce a catch block with no Exception section:

try

{

// Some code here which might

// throw non-CLS compilant exception

}

catch (Exception ex)

{

// Here we will be catching any

// CLS compliant type of exceptions

}

catch

{

// Here we will be catching any

// non-CLS compliant exceptions...

// Note that, this block on its own

// is capable of catching both compliant

// and non-compinat exceptions

}

In version 2.0 of CLR, any non-CLS compliant exception is automatically wrapped up by System.Runtime.CompilerServices.RuntimeWrappedException class which inherits from the Exception class. This class has a property which is set to the actual object which was thrown.

It is still possible to tell CLR not to wrap up the non-CLS compliant exceptions with the RuntimeWrappedException class. This is done using an attribute which affects the whole assembly:

[assembly: RuntimeCompatibility(WrapNonExceptionThrows = false)]

How to use gacutil in Vista

pedramr — Thu, 28 Dec 2006 14:49:00 GMT

Well as you probably know by now Vista’s clever UAC ensures that gacutil is not run with Administrator privileges and usually for installing and uninstalling assemblies into the gac you’ll need admin rights. A simple solution is to right-click on a Command Prompt icon and select Run as Administrator. You can now use gacutil.exe to install and uninstall assemblies.