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.