Bruno Peeters Technical Blog

Sometimes your application requires to run with administrator rights. For example to access some restricted resources on a computer. Within .Net we can adjust our application in such a way, the user is asked to run the application with elevated administrator rights. In this way the application is executed with administrator rights, hence has less restrictions. Downside of this is that also more harm can be done with bad written code (think of erasing all files on the harddrive of a user).

Read More…

The var keyword let you declare a local variable implicit. During compilation, the type of the variable is determined. It allows you to quickly define a variable, where the type of the variable is trivial. Using the var keyword can lead to some discussion when code guidelines are made up, since some people say it makes programming easier but people may also argue that code is less readable. Read More…

Multithreading allows us to execute code parallel. Each thread performs a part of the execution. A good example is a user interface and the rest of the program. With the use of threading, the user interface doesn’t frees when executing the rest of our program.

Threading can be a difficult to debug when errors occur in your program. Therefore it’s important to understand the concepts and pitfalls of threading very good when using it. Joseph Albahari wrote a very good e-book, which describes the concepts of threads and how they can be used in C#. The e-book is free and can be found here.

Design by contract is a technique, introduced by Betrand Meyer and applied within the Eiffel programming language. The concept allows a programmer to document the rights and responsibilities of everyone who uses your code. A contract (not to be confused with a .Net WCF contract) can contain the following elements:

• A precondition;
• An invariant;
• A postcondition.

Preconditions state the conditions that must be met in order to enter the method. For example a parameter “i” must have a positive value. Postconditions describe the conditions of the result of the method. An invariant states the condition which will be always be true, seen from a perspective from the calling party. Using the pre-, postconditions and invariants you can also show the correctness of a program. Read More…

When calling unmanaged code (for example C++) from within managed code, you want to be sure when accessing this unmanaged code from your managed code exceptions will be proper caught. When an access violation occurs within the unmanaged code (for example when trying to access a freed pointer), you want to catch this exception. These types of errors wil corrupt the process the unmanaged code is running in. A lot of people will put a catch (Exeption e) around it to be sure just all exceptions are caught from the (untrusted) external unmanaged code. To have a clear distingtion between corrupted process exceptions and all other exceptions, the development team of the .Net framework at Microsoft changed the CLR exception system so that all kinds of corrupted process exceptions will not be delivered anymore to your managed code.

There are however some ways to have the old CLR behavior (and retrieve the corrupted process exceptions within the CLR):
– Add an entry in your application configuration file:

legacyCorruptedState­­ExceptionsPolicy=true

An example configurationfile would look like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <runtime>
 <legacyCorruptedStateExceptionsPolicy enabled="true" />
 </runtime>
</configuration>

– Mark the method with the following attribute:

[HandleProcessCorruptedStateExceptions]

When using solution 1, your whole application will use the old mechanism. When using solution 2, only the method which is marked will be using the old mechanism.

There is a very good reason why you want to catch all process corrupted state exceptions: when using unmanaged libraries, you don’t want to crash your application due to a failure in the library. A very good in-depth description of the Unhandled Process Corrupted State exception can be found here: http://msdn.microsoft.com/en-us/magazine/dd419661.aspx

To point down problems in WCF, you can enable tracing. The WCF listeners produce valuable information to trace down errors. You can see the incomming and outgoing traffic. By default, tracing is off. To enable it, simply add the folowing section to the app.config file of your application you’re trying to debug:

<configuration>
   <system.diagnostics>
      <sources>
            <source name="System.ServiceModel" 
                    switchValue="Information, ActivityTracing"
                    propagateActivity="true">
            <listeners>
               <add name="traceListener" 
                   type="System.Diagnostics.XmlWriterTraceListener" 
                   initializeData= "c:\log\Traces.svclog" />
            </listeners>
         </source>
      </sources>
   </system.diagnostics>
</configuration>

When you run your application and WCF is used, a file “traces.svclog” is created on “c:\log”. Be sure you have rights to write to the defined location. With the use of the “Microsoft Service Trace Viewer”, which is a part of the Visual Studio suite, you can view the created file. Since this viewer is asociated by default to files of the svclog-type, you can double click on the log file to open it in the WCF viewer.

DynamicMock myExampleMock = new DynamicMock(typeof(IMyExample)); // Creates a mock object from the defined interface

myExampleMock.ExpectAndReturn(“AmethodName”, // the method name
“abc” // return value
Null  // expected arguments);

IMyExample myExampleInstance = (IMyExample)securityTokenServiceMock.MockInstance;

WPF and bindings can cause a lot of stress when your data binding doesn’t seems to work. From .Net 3.5 and up, you can enable trace information regarding bindings.

<Window x:Class="DatabindingExample" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 xmlns:diag="clr-namespace:System.Diagnostics;assembly=WindowsBase"
 Title="MyWindow" Height="300" Width="300">
 <Grid>
 <TextBox Text="{Binding Path=Name, diag:PresentationTraceSources.TraceLevel=High}" />
 </Grid>
 </Window>