Monthly Archives: March 2013

Things I fixed today #4

Leave a reply

Issue 4: SignTool stopped working

After a recent reinstall of my developer machine I received errors when compiling projects that use SignTool in the Post-build event to sign the built assembly with an authenticode certificate.

This is because the CAPICOM SDK is deprecated and won’t work out of the box with x64 versions of Windows. Also there is probably a better way to sign your assemblies (which I should research some time) these days, but since we have quite some build machines and legacy projects using this method it seemed best to get things working again.

I found the answer here:

http://www.peppercrew.nl/index.php/2011/02/windows-7-x64-signtool-error-signtool-requires-capicom-version-2-1-0-1-or-higher/

In short:
– Download the CAPICOM SDK from Microsoft
– Install it.
– Copy the capicom.dll to your SysWOW32 folder.
– Register it using the regsvr32.exe in that same folder.

Things I fixed today #3

Leave a reply

Issue 3: Problems accessing TFS’s Analysis Server from Excel

One of my co-workers wanted to use the “Create Report in Microsoft Excel” feature from the Team Explorer in Visual Studio 2012. However, once Excel had started, he was presented with the following error:

TF208056: An error occurred while the command was accessing the Analysis Services database Tfs_analysis on the server xxxxxx.

This happens because my co-worker’s machine is located in another domain, and the server name was not a FQDN server name. To fix this, I had to change the TFS Reporting configuration and set the SQL Server property to the FQDN.

First go to the TFS Administration console on your server:

Go to Reporting and then click the Edit button. You will be presented with a dialog stating that the jobs will be disabled. When you click Ok, the actual configuration screen appears:

Go to the Analysis Services tab and enter the FQDN of the SQL Server. You will have to enter the password for the data access account before you can hit the Ok button. After you hit Ok please be patient because it might take a few minutes before the dialog will disappear. After it has disappeared you should start the warehouse and analysis jobs again with the button on the TFS Administration page described above.

It can take a while before the change is visible on all clients.

Things I fixed today #2

Leave a reply

Issue 2: Another Event log Error on our TFS production server

This was also a Sharepoint issue one a bit easier to solve though. The error was:

Load control template file /_controltemplates/SearchArea.ascx failed: ‘Microsoft.SharePoint.WebControls.SearchArea,Microsoft.SharePoint,Version=12.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c’ is not allowed here because it does not extend class ‘System.Web.UI.UserControl’.

After some research I found out that the SearchArea.ascx file was left behind because we upgraded from WSS 3.0 to Sharepoint Foundation 2010. Renaming the file on disk to SearchArea.ascx_old stopped the errors from popping up. I guess you could probably remove it, but after that first issue, I didn’t want to tempt fate any more than I had to.

And now to lunch.

Things I fixed today #1

Leave a reply

Sometimes you have those days where all you do is troubleshoot and fix ‘problems’. These can be your most fulfilling days, or the most frustrating ones depending on how many of these issues you can resolve before lunch (or the end of the day for that matter).

Now and again, I can plan my day of troubleshooting, where I can pick up those event log errors on my TFS server that don’t hurt too much but keep annoying my SCOM Admin. Or perhaps fix that thing you have a work around for that takes 10 minutes extra of your time so its not deemed very urgent.

Well, today I had one of those days and I’d thought to share the solutions to the problems I have solved.

Issue 1: An Event log Error on our TFS production server

This is a Sharepoint issue, so probably not TFS specific, but the full error was:

An exception occurred when trying to issue security token: Could not connect to http://localhost:32843/SecurityTokenServiceApplication/securitytoken.svc. TCP error code 10061: No connection could be made because the target machine actively refused it 127.0.0.1:32843.

It turned out there was a application pool down on the server (The “SharePoint Web Services Root” to be precise). After starting this thing back up, the problems were solved, or so I thought. It turned out I had opened a Pandora’s box. Which, if I had known beforehand would probably have stopped me from going the route I’m about to describe, and just reinstall Sharepoint on the TFS server.

First of all the “Sharepoint Web Services” website in IIS manager was presenting strange errors: The object identifier does not represent a valid object. With no good option to be found on the Internet I recreated the website by hand (including all bindings, advanced settings, virtual directories and applications). This solved the immediate problem of the error message in the IIS manager.

But the Security Token Service still wouldn’t work. So I decided to compare the IIS settings and configuration to a working installation of Sharepoint Foundation 2010. And it turned out, our TFS server did not have the SecurityTokenServiceApplication application configured. So I created it and set it to all the correct app pools, folder etc. After that I had to change the web.confg of the SecurityToken.svc because it enabled the WindowsAuthentication Module which was already enabled.

To make a very long and tedious story short. It now works, the errors have disappeared from my event log and Sharepoint Admin Monitoring page. But next time I’ll just reinstall Sharepoint Foundation 2010 I think. This was 4 hours of my life I am not going to get back.

Windows Phone (regular Silverlight and WPF too) ListBox virtualization rendering problems

Leave a reply

I am currently working on a simple Windows Phone game and came across a peculiar problem regarding the rendering of controls inside a data bound ListBox. Whenever I had more items than could be displayed on the screen, the ListBox would automatically create a nice scrollbar, but when I scrolled down items start rendering odd. You might for instance see strange spacing between item texts, or items rendered in spots where another item should be.

After some googeling (actually quite a lot of googeling) I found out this has something to do with ListBox Virtualization. What happens is that only controls that are visible on screen get rendered to save memory and other precious resources (see more info on that here). The ListBox accomplishes this by using a VirtualizingStackPanel control. Not all controls work well with virtualization, and the control I created for my application was one of those controls.

Since I only wanted to display about 20 or so items in the ListBox and not thousands, I preferred my ListBox not to virtualize its contents. There are a few ways to do this:

Disabled scrolling

You can disable scrolling on the ListBox and wrap it in a dedicated ScrollViewer control:

<ScrollViewer>
        <ListBox Name=”myListBox” ScrollViewer.VerticalScrollBarVisibility=”Disabled”>
            ….
        </ListBox>
</ScrollViewer>

This will render the entire ListBox control as if it had all the space on the screen, and no virtualization is performed. The ScrollViewer takes care of the scrolling instead of the ListBox.

Changing the ItemsPanel of the ListBox

This looks to be the preferred way to disable virtualization of the ListBox. Templating allows you to replace the VirtualizingStackPanel with a regular one:

            <ListBox Name=”myListBox”>
                <ListBox.ItemsPanel>
                    <ItemsPanelTemplate>
                        <StackPanel />
                    </ItemsPanelTemplate>
                </ListBox.ItemsPanel>
                    ….
            </ListBox>

And there you go, no more virtualization, no more rendering problems.

Your own private NuGet gallery

Leave a reply

You probably know NuGet (and if you don’t, just click that link). And, if you write a lot of the same types of projects, you probably have a few libraries you reuse in those projects. Wouldn’t it be nice if you could install those libraries just as you install JQuery, Entity Framework or ‘your favorite package here’, but just not share that package with the entire world.

As always, there are plenty of ways to achieve this. Each has its pros and cons, and I decided to do a write-up of what is possible. So, first the options:

  • Simple file share containing packages
  • Automatically synchronized (cloud) file share containing packages
  • Internal nuget server
  • NaaS – NuGet as a Service

So now that we have the options, lets see what they are all about.

Simple file share containing packages

When you open the NuGet settings you will be able to add your own package source. This does not have to be a URL per se, but can also be a file location on a network drive or your own machine:

Package source settings

Pros:

  • Easiest to setup.
  • When using a file share on a network drive, accessible for all users inside your network.

Cons:

  • Not easily available outside your company network.

Automatically synchronized (cloud) file share containing packages

The same as above, but now you use Skydrive, Dropbox, or any other cloud storage provider to synchronize that folder in the cloud for easy access when working from home or plane.

Pros:

  • Still easy to set up (on your clients at least).
  • Package source always with you, and automatically syncs when you are online.

Cons:

  • Setting up access rights to more people than a small team (4 or 5 people) is going to be a maintenance nightmare.
  • Try explaining a Dropbox or Skydrive installation on your build server to Corporate IT.

Internal NuGet server

In this scenario you setup your own NuGet server, which will probably consist of a website and some web services hosted on IIS (I am not sure if there are any non .NET NuGet servers out there). There are a few options with a varying degree of features and installation effort needed.

Pros:

  • Once installed, easy to expose to outside the local network so you can access it from anywhere.
  • Works just like the official NuGet Package Source, which means that you don’t need separate build scripts for packages you want to push to the official source and the internal source.
  • Easily incorporated in automatic build scenarios.

Cons:

  • Hard(er) to set up.

NuGet as a Service

I recently found MyGet, which hosts NuGet feeds. The idea is quite simple you register with them, a feed is created for you, and you can contribute to this feed. They have 4 different plans of which only 1 is free. More details on those plans here.

Pros:

  • Easy to set up.
  • The enterprise plan has a lot of nice options.
  • Easily incorporated in automatic build scenarios.
  • Available wherever you have an internet connection.

Cons:

  • Advanced and user/quota management features come at a price.

Conclusion

As you can see, there are plenty of options to create your own NuGet feed. I have chosen to install my own NuGet server (because I only found out about MyGet after I finished, and I love to get my hands dirty with that kind of stuff). So I’ll probably write a tutorial on that one some day.

If you need/want a private NuGet package feed is totally up to you. But if you do, there are plenty of options to get you started. And I hope this post has helped you make a decision.