Problem

Jenkins dashboard shows following simian analysis:

But after clicking one item I get:

Solution

My simian call was:

.\tools\Simian\bin\simian-2.3.33.exe ./src/**/*.cs -formatter=xml:.\bin\Simian.Result.xml -threshold=10 -excludes="**/*.Designer.cs" -excludes="**/*Fixture*.cs" -excludes="**/*.g.cs" -excludes="**/*.xaml.cs" -failOnDuplication-

but the folder prefix (‘./’) for current folder in front of (‘src/**/*.cs’)  is wrong.

Deleting the unnecessary chars lets the system work:

Last week I get the information directly from Microsoft, that at build machines SDKs must be installed to guarantee that MSBuild works well in some circumstances.

We have the problem, that a self-containing build should include all necessary build artifacts – particularly Silverlight stuff. I tried to encapsulate the special steps in own targets and a build was finally possible (see my former posts). But at local machines without installed Silverlight stuff it gives problems for problems. Because reason of time finally I decide to go the Microsoft way – they break my volition

Only one thing I left in my DevTree: the WebApplication target. This stuff is not included in the Silverlight SDK – no idea where it comes from. To avoid the build breaks on our continuous integration server I reference this target in my DevTree self.

These lines:

  <ImportGroup Condition=" '$(Configuration)' == 'Debug' ">
    <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
  </ImportGroup>
  <ImportGroup Condition=" '$(Configuration)' != 'Debug' ">
    <!-- leider nicht von Visual Studio akzeptiert -->
    <Import Project="..\..\..\tools\WebApplications\Microsoft.WebApplication.targets" />
    <!-- -->
  </ImportGroup>

Problem

this code does not work

Type t = typeof(ESRI.ArcGIS.Framework.AppRefClass);
System.Object obj = Activator.CreateInstance(t);

but yet this code

Type t = Type.GetTypeFromCLSID(typeof(ESRI.ArcGIS.Framework.AppRefClass).GUID);
System.Object obj = Activator.CreateInstance(t);

Reason

In the first variant the runtime tries to cast to AppRefClass . This is not possible.

And in the second one, the runtime does not knows anything about AppRefClass. So it leave it as IUnknown.

(originally communicated by my co-worker Ralf)

Why such constructs are included in the csproj-Files?

<CodeAnalysisRuleSetDirectories>;c:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\\Rule Sets</CodeAnalysisRuleSetDirectories>
<CodeAnalysisRuleDirectories>;c:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\\Rules</CodeAnalysisRuleDirectories>

So it every projects needs some manual steps to clean the project file so the solution could be build on a continuous integration server. That annoying!

And also in a Visual Studio mixed editions team that’s too specific for the ultimate edition.

As good as Visual Studio in most cases is, sometimes it is really far away from professional coding fundamentals and best practices.

Problem

Normally I try to have my continuous integration as most a possible toolset free to ensure that no local stuff could have an impact to my build.

My Silverlight app references a special compile target in a folder outside my developer tree:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

So I copied the stuff from this folder to a local one and changed the call to this target in my csproj:

<Import Project="..\..\..\tools\WebApplications\Microsoft.WebApplication.targets" />

And now Visual Studio Conversion Wizard welcomes my with this:

Solution

Regardless of which line I write – this conversion comes back again and again, if the line has another form than

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

So it seems that there is no simple way to change this behaviour.

Workaraound

I must accept, that this line must be in the csproj and to run the build the toolset must be copied to the build server at the correct location.

So go to your development machine where Visual Studio is installed and copy the folder “C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications” to your build server at the equivalent location.

Xmas wishes to Microsoft:

Please provide technologies to let us developers bundle all needed stuff for a project in one developer tree. It should be possible that one checkout starts us up! No additional installations regardless whether it is a developing machine or dedicated build or continuous integration server.

Silverlight is only one example, code analysis configurations could also be terrible and much more …

Problem

Normally PostSharp runs fine on unattended build servers. So on our global Jenkins continuous integration server PostSharp does the job.

But on my local TeamCity continuous integration server I got the following error:

POSTSHARP error PS0127: The aspect 'EsriDE.Commons.Logging.Aop.PostSharp.LoggingAspectAttribute' uses non-licensed features (Basic Features). Please visit http://www.sharpcrafters.com/ to acquire a license of PostSharp. 
POSTSHARP error PS0154: Information regarding the previous message: the installed user license is: "". 
POSTSHARP error PS0060: The processing of module "EsriDE.Maintenance.LoginExtension.dll" was not successful. 

Okay – so install the license via a target in the developer tree. Like described in

Configuring PostSharp - Creating a file PostSharp.Custom.targets or Deploying License Keys for a Team

This throws a new error:

C:\Program Files (x86)\TeamCity\buildAgent\work\bf9b0bb7766c4536\lib\Nuget-Packages\PostSharp.2.1.5.1\tools\PostSharp.targets(173, 5): Property 'PostSharpLicenseKey' is deprecated.

and indeed: this option was discontinued

Announcing PostSharp 2.1 CTP 2 (see section “License Management”)

Solution

Note to self: RTFM

Deploying PostSharp into a Source Repository - Adding PostSharp to your project using PostSharp HQ

Activate the license you got with the one of the first mails from SharpCrafters and everything works like expected.

Problem

Our global Jenkins continuous integration server throws this error during compile step. My local TeamCity continuous integration server runs fine. What is the difference.

Background

I integrate some static code analysis steps via MSBuild-targets in the csproj files.

To allow a fast developing without a code analysis for ever compiling I bound these targets only to RELEASE-configuration.

With the MSBuild element <ImportGroup> only one condition must be specified. So my construct was:

<ImportGroup Condition="'$(Configuration)'=='Release'">
    <Import Project="..\..\..\tools\Fxcop\EsriDE.FxCop.targets" />
    <Import Project="..\..\..\tools\StyleCop\StyleCop.targets" />
</ImportGroup>

That works fine in Visual Studio and TeamCity.

But Jenkins allows to specify the MSBuild version:

Because my target framework is .NET 3.5 I decide to choose the entry .NETv3.5-x86.

And this was the failure. The MSBuild element <ImportGroup> is new in .NET 4.0

Solution

With the following options everything runs fine:

BTW: Maybe that some combinations of MSBuild version and toolsversion switch could also fix this error.

Problem

A continuous integration server should only have a minimal toolset installed. This ensures that no unwanted libraries could affect the build and other steps.

Clearly that with this slogan also StyleCop should not be installed to the CI server. But we wanna have this analysis as an part of the whole build.

Solution

Prerequisites

First at all we need the necessary files from StyleCop (the core assemblies and the target).

The easiest way is to download the MSI of StyleCop, install the software and copy the relevant artifacts to a tools folder in our developer tree.

For a default installation you will find the assemblies under the program files folder and the target file under the MSBuild folder. You could copy all together to one folder.

Now deinstall the software to ensure, that your project local environment works (no impact from installed stuff).

Configure your environment

To run StyleCop from the target file it must be edited. Change the third line

from

<UsingTask AssemblyFile="$(ProgramFiles)\StyleCop 4.6\StyleCop.dll" TaskName="StyleCopTask"/>

to

<UsingTask AssemblyFile="StyleCop.dll" TaskName="StyleCopTask"/>

Configure your csproj files

In the last step we bore up all csproj files of our solution. Next to the c#-compile target we call the StyleCop target:

<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="..\..\..\tools\StyleCop\StyleCop.targets" />

Take care to adjust the correct relativ folder from csproj- to target- file.

Problem

When using xUnit and constructs like Debug.WriteLine the DbgView-tool does not show the written output anymore.

Solution

Add a new Listener – for example:

Debug.Listeners.Add(new DefaultTraceListener());

Problem

I must go back to an older package version (from 1.1.0.0 to 1.0.0.0) but the Package Manager Console does not allow this.

With the command

Update-Package EsriDE.Commons.System.Utils -Version 1.0.0.0

I got the error:

Update-Package : Already referencing a newer version of 'EsriDE.Commons.System.Utils'.

Solution

Don’t worry. You could uninstall the package

Uninstall-Package EsriDE.Commons.System.Utils -Version 1.1.0.0

and install the older one instead.

Install-Package EsriDE.Commons.System.Utils -Version 1.0.0.0

As an GWB-influencer I had the chance to review SmartAssembly.

Because obfuscation is an important part in protecting intellectual property this review chance was a good start for this. The first few clicks show that not only obfuscation could be made with SmartAssembly but also some other very interesting things.

The complete review could be read here: GWB-Review SmartAssembly

Motivation

During programming suddenly this error (“Failure has occurred while loading a type”) was thrown by accessing a artifact of a referenced library.

In such cases I take the assembly fusion logger fuslogvw to search for problems of loading assemblies. Sometimes an old version from a not expected folder is binded. But all bindings were correct.

Problem

After several hour I got the right hint. Because the assembly is a COM+ one, there are some registration things in die background – and I don’t mean the regsrv-stuff!

And there was one step which access the GUID of the type under “HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{4E83E98D-0D8F-4949-8436-0F001CFE5039}”.

Reason for the problem

Than I remembered, that I started developing of the COM+ library as a normal user – and during runtime I got two errors regarding the accessing of the following keys:

System.EnterpriseServices.RegistrationException : You must have administrative credentials to perform this task. Contact your system administrator for assistance.
----> System.EnterpriseServices.RegistrationException : Failed to register assembly 'ErpUnlinkedObjectsRestSoe, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0123456789abcdef'.
----> System.UnauthorizedAccessException : Access to the registry key 'HKEY_CLASSES_ROOT\ErpUnlinkedObjectsRestSoe' is denied.

I created this key with administrative credentials:

and set the permissions for normal users:

Because after each run the key is deleted I decided to set a deny for delete. So the key stays over the following runs.

The following error

System.EnterpriseServices.RegistrationException : You must have administrative credentials to perform this task. Contact your system administrator for assistance.
----> System.EnterpriseServices.RegistrationException : Failed to register assembly 'ErpUnlinkedObjectsRestSoe, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0123456789abcdef'.
----> System.UnauthorizedAccessException : Access to the registry key 'HKEY_CLASSES_ROOT\CLSID\{4E83E98D-0D8F-4949-8436-0F001CFE5039}' is denied.

I resolved like above.

And these keys were now the basic evil.

Solution

I deleted the key and started my Visual Studio with administrative credentials to run the code.

Intro

If you want to test the internals of a productive assembly you must mark the assembly with the InternalsVisibleTo-attribute. This attribute has only one constructor which needs the name of the testing assembly.

http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.internalsvisibletoattribute.aspx

So this looks like:

[assembly: InternalsVisibleTo("UnlinkedObjectsRestSoe.Tests")]

Visual Studio and 3rd party plugins uses the string to mark referencing artifacts with permitted/denied hints.

Strong named assemblies

If the productive assembly is strong named you get with this (simple) style an error:

Friend assembly reference 'UnlinkedObjectsRestSoe.Tests' is invalid. Strong-name signed assemblies must specify a public key in their InternalsVisibleTo declarations.

Okay – this makes sense, because a strong named assembly could only reference strong name assemblies. So we must sign the testing project too.

And we must set some additional information in the code.

Public Key Token

In some articles is described, that you could use the public key token for the additional information. This is a wrong information! But let us go the steps I gone for a better understanding.

You could extract the public key token of your keyfile over two steps

1. extract the public key from the keyfile with
   sn –p <keyfile.snk> <keyfile.snk.PublicKey>
2. show the public key token with
   sn -t <keyfile.snk.PublicKey>

Now this public key token is set:

[assembly: InternalsVisibleTo("UnlinkedObjectsRestSoe.Tests, PublicKeyToken<"123456789abscdef">)]

The public key token must be wrapped in angle brackets, otherwise the compiler error is the same.

Furthermore for Visual Studio is only the name of the referencing assembly interesting – after the comma you could write nonsense.

Till here all works fine.

The problem came up when you reference internals from the productive assembly in your testing assembly.

The compiler throws something like:

'UnlinkedObjectsRestSoe.Artifact' does not contain a definition for 'Foo' and no extension method 'Foo' accepting a first argument of type 'UnlinkedObjectsRestSoe.Artifact' could be found (are you missing a using directive or an assembly reference?)   

Public Key

Now it is time for the right way: use public key instead public key token!

To show the public key you use: sn –tp <keyfile.snk.PublicKey>

This outputs a very long key over five lines. Copy it and add the lines together (e.g. via notepad)

Next change in code the attribute line to:

[assembly: InternalsVisibleTo("UnlinkedObjectsRestSoe.Tests, PublicKey=123456789...abscdef")]

In this case without angle brackets!

Conclusion

Fine – now you have:

• correct behaviour of Visual Studio and 3rd party plugins concerning squiggles under referencing code
• a compileable productive project
• a compilable testing project

Motivation

Often you want to have the possibility to call a special abstract or virtual Initialize-method in a constructor of a base class to set individual initializing things in an override of this Initialize-method in a derived class.

This is similar to the GOF-Pattern “Template Method”. But with C# this ends up with a warning “Virtual member call in constructor”. Why we get this warning?

To show the effect of this approach, lets have a look at the source and the calling graph during runtime:

Consequence

You will see, that the constructor of the derived class is called *after* the call of the Initialize-method of this class. So you should be carefully if you set up things in the derived constructor and use later in the Initialize-method. Samples of such information could be identity or logging stuff.

But if you don’t have a correlation between the constructor and the Initialize-method you could use it.

Essentials

Run the bash for this as administrator. The shortcut is located in the Git installation folder. "%ProgramFiles(x86)%\Git”.

Good Setting for the layout are:

• Screnn buffer size
• Width: 160
• Height: 3000
• Windows size
• Width: 160
• Height: 75

A detail explanation could be found under Unable to modify git bash Windows shortcut - Full Instructions

Additonals

With the Console enhancement project (Console Enhancement Project at SourceForge) it’s a lot more fun to work with console.

Settings for console App

• Activate “Save settings to user directory”
• On tree node “Console” set the Window and Buffer sizes like above
• On tree node “Appearance” set “Snap to desktop edges” with a distance of 10 pixels
• On tree node “Appearance > More …” set Alpha canals for transparency to 30 for the active and 150 for the inactive window
• On tree node “Behavior” activate “Copy on select”

Settings for Git Shell

1. Open the settings with Edit > Settings…
2. Goto tre node “Tabs”
3. Press “Add”-Button to add a new tab specification which you could later use
4. Name it “Git Bash”
5. Specify the Shell, for instance with
   C:\Program Files (x86)\Git\bin\sh.exe --login –i
6. Setup your mostly used directory which should be the active directory, for instance
   c:\Projects
7. Setup a cursor style, I like XTem and Pulse in grey

Remarks

Have a look at the tree node “Hotkeys > Mouse” to get a understanding how to select some text parts in the console window