The ‘RadLangSvc.Package, RadLangSvc.VS, Version = 10.0.0.0, Culture = neutral, PublicKeyToken = 89845dcd8080cc91’ failed to load

For some while now I’ve been coming across this problem with Visual Studio 2010. It’s an odd one because to all intents and purposes the Schema Compare tool looks like it should work but when I come to open a SQL file I get this error.

I tried lots of things, most time-consuming of all a full install of Visual Studio. I did this six times and each time noticed an error with the SQL component but because of the way the installer worked I wasn’t able to get at it. If you’ve experienced this error you’ll know what I’m on about.

However, today I managed to get it working, and therefore I’m posting this info and this link. I found the fix here. I only needed to run the post installation MSI project.

Just for reference I’m pasting the content of Vikram’s post below but all credit goes to him.

 

A couple of days ago, using the Schema Compare tool included in Visual Studio 2010 Ultimate, I ran into an error that reads:

“The ‘RadLangSvc.Package, RadLangSvc.VS, Version = 10.0.0.0, Culture = neutral, PublicKeyToken = 89845dcd8080cc91’ package did not load Correctly.”

The system continues to operate apparently, only after the settings when we kick off the comparison, the environment crashes fatal.
After a little ‘research I found this post which in turn refers to that.

The problem is essentially due to the installation of SQL Server 2008 R2, which affected various components associated with the SQL scripting. The same symptoms occur it is also using the SQL shell included in VS, even though I had installed the R2 for a while, ‘I have not noticed it before because I always use the environment to SQL Server Management Studio.
The proposed solution is to simply re-run the post installation

DACProjectSystemSetup_enu.msi

located on the installation disc in the folder of VS 2010

\ WCU \ DAC

but for more serious problems may need to rerun the other two in the same folder installer

TSqlLanguageService_enu.msi
DACFramework_enu.msi

take care of it in VS closed and once the installation is complete, there is no need to restart everything is already back in place.

Use the new keyword if hiding was intended

A couple of months ago at work we put some new web services into production. All seemed to go well and everything seemed nice and fast but we noticed that some of these services were using a lot of CPU and memory. We had used JMeter to load test these services quite extensively so I was fairly convinced that there wasn’t really a memory leak but, of course, one can never be too certain.

Now, in these web services we know that one of the methods was used pretty extensively so to begin with I focussed my efforts on it to see if there was anything that might explain this curious behaviour.

It turns out that there was a memory leak and it wasn’t in the depths of the code but right at the top. I’ve got an ASMX and its code behind starts like this:

public class CustomWeb: System.Web.Services.WebService {

    private CustomService customService;
    private SitesListService sitesListService;

    public CustomWeb() {
         customService= new CustomService();
        sitesListService = new SitesListService();
    }

    public void Dispose() {
        customService= null;
        sitesListService = null;
        base.Dispose();
    }

I’ve removed most of the code but you can see a fairly plain constructor and a dispose method. Pretty basic stuff. This compiles perfectly well but there was a warning displayed regarding the Dispose method. This says.

CustomWeb.Dispose() hides inherited member ‘System.ComponentModel.MarshallByValueComponent.Dispose() Use the new keyword if hiding was intended.

Initially I read this quite literally. I didn’t want my Dispose method to be hidden in fact I wanted it to be called to mark the objects created in the constructor to be null to free up memory. As this web method inherits from the WebService I thought that perhaps its Dispose method needed to be over ridden but doing that caused an error to be shown.

I’ve never used the new keyword in a method signature before and doing so to hide a method didn’t really make sense. However, that apparently is what I should be doing. This was the cause of my memory leak. My Dispose method should be written like this:

public new void Dispose() {
    customService = null;
    sitesListService = null;
    base.Dispose();
}

It would seem that the previous way without using the new keyword prevented the base.Dispose method from being called so therefore every request to the web service was resulting in CPU usage and memory usage being much higher than expected. At a guess there might have been less damage caused by not having a custom Dispose method at all, that way the base method would be called and the resources freed. The new objects created in the constructor would have eventually been picked up by the garbage collector.

However, I’m glad we made this mistake since it illustrates a couple of things. Firstly, don’t ignore the warnings. Yes, your code might have built but it’s worth checking the warnings. The clues in the name after all. Secondly, now I know a little bit more about web services. It’s odd to think that these three letters ‘new’ have resulted in memory for my web services running at a consistent level, whereas previously they used to climb to about 1GB in size before then dropping, and the CPU usage now being 3 – 9% (depending on load) as opposed to 35% – 60%. That’s quite something.