Archive for the 'Visual Studio' Category

I’ve just been asked through the “Ask” widget on the side of this blog on Yedda (my day job) this question:

Yedda � People. Sharing. Knowledge.Where is sos.dll for .net 3.5?

I installed Visual Studio 2008, but I don’t see sos.dll in the Microsoft.NET\Framework\v3.5 directory? What’s up with that?

Topics: , ,

Asked by dannyR on January 03, 2008

View the entire discussion on Yedda

To which I replied:

Yedda � People. Sharing. Knowledge.Where is sos.dll for .net 3.5?

There is a bit of confusion as to the .NET Framework versions as opposed to the CLR (Common Language Runtime) versions.

Up until .NET Framework 2.0, the CLR versions advanced side by side with the versions of the framework.

Starting from .NET Framework v3.0, the version of the CLR stated at 2.0 (there was no significant change in the CLR itself) and the framework’s version kept on going forward.

.NET Framework v3.5 actually runs on CLR 2.0 SP1.

This means that you can should be able to use the SOS.dll located at Microsoft.NET\Framework\v2.0.50727 with either Visual Studio (as I’ve explained on this post) or with WinDbg.

Dave Broman of Microsoft has written a post about the mapping of the versions of the .NET Framework to the version of the CLR. Do mind that as Dave states in his post, its the way he figures things up in his head and not the official documentation on this matter.

Topics: , ,

Answered by Eran on January 03, 2008

View the entire discussion on Yedda

I know its a bit confusing and I’m not really sure why Microsoft detached the versions of the Framework from the versions of CLR (well, I can understand some of the thoughts leading to this but I don’t think it was that good of a move) but Dave’s excellent post does put things in perspective and allows figuring out in what version of the CLR you are actually using.

The ASP.NET Repeater control is a very useful patten that minimizes code and allows you to use templates to represent repetitive data.

All of you are probably familiar with it and use it quite often.

Yesterday I had a big fight with the repeater control, and since most of the Internet (actually search engines for that matter) is filled with lots of data about the Repeater control and how to use it, I couldn’t find the answer I was looking for.

Apparently it was staring me right in the face.

The problem was that I needed to display a list of words with a comma separator and they should have looked like this:

word a, word b, word c, word d

but what I got was this:

word a , word b , word c , word d

An additional and unwanted extra space before the comma.

That code that I used in the ASPX file was this:

<asp:Repeater>

<ItemTemplate>

<% #Eval(“Text”) %>

</ItemTemplate>

<SeparatorTemplate>, </SeparatorTemplate>

</asp:Repeater>

All seems well, right? there is no space before the comma in the separator template, but there was when the whole thing was rendered.

The fix was quite stupid (and is quite fragile):

<asp:Repeater>

<ItemTemplate>

<% #Eval(“Text”) %></ItemTemplate>

<SeparatorTemplate>, </SeparatorTemplate>

</asp:Repeater>

The extra enter which placed the </ItemTemplate> element in a new line was the cause of this problem. That new line was translated in this case into a single space which made everything look weird.

It seem that the Repeater control (and possibly other template based ASP.NET controls) are sensitive to the ASPX formatting. They are not trimming the edges of content that resides inside the template ASPX element, thus making them susceptible for formatting weirdness.

The worst problem of all is that when you use Visual Studio’s auto formating (Ctrl-E, Ctrl-D by default, if I’m not mistaken) it will ruin the layout and you might end up with a Repeater that has an extra space even if you didn’t want it.

I can understand why the edges were not trimmed, so that you can and should be able to enter white spaces as part of your template, but Visual Studio itself when formatting a document to be more clearly read will mess things up and that is the true problem.

While this is not a “real” advanced .NET debugging issue and I didn’t use any cool tools to figure it out it annoying nonetheless 🙂

Sometimes you need to to debug something that is simply doesn’t work as it should. It doesn’t throw an error so it’s a bit trickers to debug it with WinDbg or MDbg. In addition to that, you simply cannot (or should not) install a full blown Visual Studio installation on that machine.

For these scenarios exactly, Visual Studio’s remote debugging abilities exist.

At work, a friend had to debug such a problem. It didn’t throw an error and it worked on his machine (it always works on the developer’s machine 😉 ) but didn’t work on one of our test servers.

In order for the remote debugger of Visual Studio to work, one must install the Remote Debugger package that comes on the Visual Studio DVD on the remote computer. It’s a relatively small footprint installations.

NOTE: Be sure NOT to install this on a production server since the remote debugger needs to somehow talk to your debugger and it uses the network for that. Installing this (or at least keeping it enabled) on a production server might put the server at risk of being hacked!

Installing is the easy part. Now comes the configuration part since the debugging service authenticates both ways (both the machine running Visual Studio needs to authenticates on the remote machine, and the remote machine needs to authenticate on the machine running Visual Studio)

I’ve found two interesting article that can help you do that. One is a Knowledge Base article from Microsoft, the other a blog post for figuring out how to configure things when you are running in a domain-less (or domain different) envrionment:

  1. How to implement remote debugging in Visual Studio 2005
  2. Remote Debugging without domain accounts – from greggm’s blog.

If you follow these two articles you’ll get it up and running in no time.

If all else fails, printf debugging will probably still work (I’m referring to the broader definition of printf debugging which includes logging to a file/event log/whatever and not actually using printf’s to log stuff).

Did you know that you can use SOS from within Visual Studio 2005, not just from WinDbg?
It has been previously discussed in a couple of places but most people don’t know it is possible to do that.

“Why should I use the SOS extension from within Visual Studio?”, you are probably asking.
The answer is quite simple.

Visual Studio is a rich debugger that shows us most of the information we want to know but it doesn’t show us a few important things like the actual size of an object and all of its references and who is referencing our object. While these things are not straight forward in Visual Studio, they are very easy to accomplish in SOS. For example, you can run the following command in SOS:

  • !objsize – to find out the actual size of the object and all of its referenced objects
  • !gcroot – to find who is referencing our object
  • !dumpheap – to see what’s all the stuff that we have on the heap. By using the -gen [generation number] parameter with !dumpheap, we can see all the objects that are currently in that generation
  • !SyncBlk – find out which managed locks are locked at the moment (I’ve talked about it before)

So, how do we actually do that?

Well, the first thing you need to do is enable “unmanaged debugging” by going to the “Project Properties” -> “Debugging” -> “Enable Unmanaged Debugging”.

After doing that, you can stop somewhere in your program, open the “Immediate” window (Debug -> Windows -> Immediate) and type:

.load sos

This will load the SOS extension. From there on you have most of the commands of the SOS extension at your disposal.
You might need to set the symbols path by calling .sympath, just like you would do in WinDbg.

An added bonus to this whole thing is that it also works on Visual Studio 2003, so you get to use it even with .NET Framework 1.1.

Francisco Martinez has some interesting tools that he developed to make it a bit easier to develop to .NET application to Mono using Visual Studio .NET.

These tools allow you to create a makefile from a Visual Studio project file enabling you to build the project in a complete Mono environment as well as import and export MonoDevelop project files from and into Visual Studio Project files.
It will also enable you to run your compiled code under Mono instead of the Microsoft .NET Runtime directly from the Visual Studio IDE.

I’ve been following the Mono project since its inception and it has come a long way since.

I know there are (and are going to be) a lot of legal issues that can do a lot of problems in regards to the project, but I still think its a necessary and welcome addition to the development platforms available on the different Linux flavors and UN*X operating systems.

I wonder if someone is planning to write a WinDbg extension to handle Mono 😉
Though I’m not sure there will be a lot of market for it. People will probably use the Microsoft .NET Runtime for Windows development and/or deployment and Mono for a Non Windows development / Deployment.

I guess only time will tell 🙂

I’ve just stumbled upon this blog, by Microsofty named jimgries.

It has some wonderful tips and trick on how to debug stuff using Visual Studio 2005.

I specifically liked this post about tracepoints as well as this post about C#’s and J#’s ability to add an “Object ID” on objects to track them down around the application.

It’s definitly going on my subscribed list!

I had a stupid problem today compiling MDbg in VS2005 and I thought I should share it with you so others won’t waste 10min for their lives.

I have both VS2003 and VS2005 (the RTM of course 😉 ) installed on my machine.

The MDbg source code that I talked about in the previous post, has one assembly called corapi2 which only includes IL source code since it has a few COM marshaling trickes that are not covered by IL code generated from C#.

corapi2 has a .csproj file and is a part of the MDbg solution for ease of use. it doesn’t compile C# code, but rather run a post build command that runs ILAsm.

I tried to compile the soultion but it failed saying that it cannot recognize the interface ICorDebugProcessEnum.

I started to investigate and saw that it is suppose to be declared in corapi2.
I dropped corapi2.dll into Reflector and saw no .NET code. Strange.

I tried manually compiling it and go a funny error about uint32 in line 88. Go figure.
Then I noticed that I’m running ILAsm of Framework 1.1 and not Framework 2.0 since, for some reason I have the Framework 1.1 folder in my PATH environment variable.

I open the the Visual Studio 2005 Command Prompt, changed dir to the Mdbg folder and run nmake (which is the other option of compiling it) and it compiled with no special problems :-).

Beware of the PATH!

[UPDATE – 9:30AM]
[Added some of the links from Rico’s post and some more input on them]

This is a bit off topic, but I’d thought I’ll still give it a post since, as we all know, the best way to debug is to not debug at all. Avoiding common pitfalls and understanding how things work can save hours of debugging work at a later time.

Anyhow, I’ve stumbled upon a post by Rico Mariani in his blog about Whidbey Performance Opportunities.

(SIDE NOTE: his blog is full of interesting things since his current position is in the CLR performance team. If there is someone that knows how to squeeze extra performance from the CLR that’s him)

This post talks about some of the new things Whidbey (Visual Studio 2005) has to offer as well as the new .NET CLR 2.0.

The post offer links to each subject with additional information such as:

  • Review by Jason Zander of NGen – Its a little old but give a good insight as to what this tool does and how and when to use it. Keep in mind, as stated in the post, that NGen in v1.0 and v1.1 was mainly created for usage of the runtime itself. It got revamped a bit in Whidbey so that it is much better.
  • NGen is only good for a specific version of the CLR. If a new service pack was installed, there is a need to re-NGen your assemblies, otherwise their native image will be ignored and they will be considered as standard .NET assemblies that were not NGen’ed. As part of WinFX (which will be released in Windows codenamed Longhorn, now named Windows Vista) there is a new service called Native Image Service that does this tedious task of figuring out that certain assemblies needs to be re-NGen’ed and does that. You can use ceratin attributes in an assembly to give it better understanding of what to actually do with your assembly. You can read more about it here.
  • Another great post by Rico Mariani titled Six Questions About Generics and Performance.
  • An excellent two pieces post by Maoni about using GC Efficiently, Part1 and Part2.
  • Dodge Common Performance Pitfalls to Craft Speedy Applications using Reflection by Joel Pobar on this month’s (July) MSDN Magazine issue. It talks about imporvments of the reflection implementation in .NET 2.0 as well as the usage of some new APIs that lets you do things more quickly.Read, understand, let it sink in and by the time you’ll start working with it you’ll be better prepared.