Visual Studio Command Prompt

Here is another useful tip from Mark Comeau, this guy needs his own Blog. Then again I'm glad he hasn't got one. What would I write about. :)

Do you find yourself in the Visual Studio Command Prompt from time to time? Of course you do. Do you get to it via:

Start->Programs->Visual Studio .Net 2003->Visual Studio .Net Tools->Visual Studio .NET 2003 Command Prompt

Hopefully you have a shortcut that is closer to your desktop or start menu.

When you open it what directory are you in? Do you have to then use your vast knowledge of command line directory traversal to get to your source code or whatever it is your looking for?

Would you like to right click on a directory in windows explorer and open a Visual Studio Command Prompt already set to that directory?

Just add these entries to your registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shell\cmd_vs]
@="Open VS Command Prompt Here"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shell\cmd_vs\command]
@="cmd.exe /k \"C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Common7\\Tools\\vsvars32.bat\""

If you would like the same functionality from a Drive also add this to your registry.

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Drive\shell\cmd_vs]
@="Open VS Command Prompt Here"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Drive\shell\cmd_vs\command]
@="cmd.exe /k \"C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Common7\\Tools\\vsvars32.bat\""


Thanks Mark thats a good one.


 

.NET 2.0: See it Live! - Dec 9, 2003 - Toronto - -11

On December 9th, ObjectSharp Consulting will present an in depth sneak peak of the next release of .NET: Visual Studio .NET 2.0 (code-named "Whidbey"). This release of Visual Studio and .NET framework will offer innovations and enhancements to the class libraries, CLR, programming languages and the Integrated Development Environment (IDE). We will share the latest material from the Microsoft PDC in L.A. and from the Bigger Better Basic tour. Attend this free event and learn how you can architect your applications today to ensure a smooth transition to the next version of .NET.

.NET 2.0
A Whidbey Preview

Paramount Theatre
259 Richmond St. West,
Toronto,
Queen St West District

8:30-11:30am


Click here to register!

Partial Classes

I'm really liking this idea of Partial Classes that is coming in .Net 2.0.

When I first heard about it, I thought “now that is going to be confusing“. But I've been playing with it in Whidbey and I think it's going to be cool. Both VB.NET (When do we get to stop calling it VB.NET and just call it VB again)  and C# allow you to split your class across two files. Although the syntax is slightly different.

C# - Each part of the class has the same definition as seen below

  • public partial class MyClass
  • public partial class MyClass

VB.NET - There is a main class and all others expand on that like this

  • Public Class MyClass
  • Expands Class MyClass

For those who are wondering, The two files must reside in the same assembly. They are actually combined at compile time.

I have been thinking about how useful this will be. Here are some of the uses I can see for Partial Classes.

  1. That section of code generated by the designer that you shouldn't touch, can go in another file (And in Whidbey it will)
  2. Extending a Typed Dataset or any other auto generated class (This is the same basic reason as number 1)
  3. Code Behind, I assume the ASP.NET team will use partial classes to implement code behind
  4. Multiple developers, two developers can work on different areas of a class at the same time without worrying about merging changes. Therefore it could be used to logically divide a class, think of it like regions on steroids.

What else? I'm curious to hear about others peoples ideas for Partial Classes.

 

Upating Performance Counters from ASP.NET

While there are a number of quite useful articles about how to access and increment PerformanceCounters through the .NET Framework (the PerformanceCounter class description on MSDN and Creating Custom Performance Counters, also on MSDN to name two), the actual deployment of a web service (or any ASP.NET application, as it turns out) is not so thoroughly covered. 

The biggest problem surrounding the move into production of an ASP.NET application that updates performance counters is permissions.  By default, in order to increment a performance counter, the user needs to have Administrator or Power User rights.  You could change the processModel value in machine.config to System, but that leaves a security hole wide enough to drive an 18-wheeler through.  Which is another way of saying “Don't do this!!!!!”.

For completeness, the event log entry that appear as a result of the lack of permissions is as follows:

Event ID:  1000
Source: Perflib
Access to performance data was denied to ASPNET as attempted from C:\WINNT\Microsoft.NET\Framework\v1.1.4322\aspnet_wp.exe

Also, on the actual call to increment the PerformanceCounter, the following exception is thrown:

System.ComponentModel.Win32Exception: Access is denied

with the stack trace pointing to the GetData method in the PerformanceMonitor class.

As it turns out, the permission set that is required is much smaller than running as “System”.  In the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib, set the Access Control List so that the ASPNET user has Full Control.  Voila, the problem goes away.

Source Safe Performance

Here are a couple of good tips for making source safe run a little better over the network.

I have seen these before but a client (Mark Comeau) recently reminded me of them.

  1. Change your VSS Folder for temporary files to be local. It will default to where the VSS Database is installed. Tools->Options...-> General Tab
  2. Put your ss.ini on your local machine. This file normally is in the \users\ You can move it locally and change the \users.txt file to tell Source Safe where you put it.

Less network chatter means a better response time when using Source Safe over the network.

 

 

Between the Lines Article

As much as I don't like to toot my own horn, I'm proud of the fact that I'm now officially published on an MSDN site.  If that isn't worth a “Woo Hoo!!”, I don't know what is.

XAML IntelliSence Patch for PDC "Whidbey" & "Longhorn"

Overview The IntelliSense in the PDC bits while editing XAML had problems inside Style elements as well as when completing tags and reformatting. This patch addresses those issues to improve the developer experience.

System Requirements
PDC '03 release of Longhorn
PDC '03 release of Visual Studio .NET "Whidbey"

Download: XAML IntelliSence Patch for PDC Visual Studio .NET Whidbey

Whidbey

Next Tuesday (Dec 9th) Object Sharp is hosting a free half day seminar on VS.NET 2.0 (Code Named Whidbey).  We'll show a lot of the new features in the IDE like snipits, expansions, snap lines and smart tags. We'll show you new features in C# and VB.NET, also ADO.NET and ASP.NET.

I think you will really enjoy this informal look at the next wave from a developers perspective.

Come on out. It's free and you just might learn something. You can register here.

 

VB who knew?

I haven't written anything in my Blog for quit some time. Mostly because I have been preparing for presentations. We helped Microsoft with their Bigger Better Basic cross Canada tour last month. I spoke in Toronto, Ottawa and Vancouver. It was great. We met lots of wonderful people who were all very excited about Web Services and Client Applications. I'm sure you can tell by the name that the show was for VB developers. My colleagues will tell you it's pretty humorous to say the least that I would wind up speaking to VB developers about how great VB.NET is to develop in.

At one time I would have nothing to do with VB. It was not Object Oriented, that was enough right there. ADO was not great, ASP was not great. It was just too hard to do anything. Well I'm hear to tell you, “VB has come a long way baby“. I was speaking with someone at the show on this very subject. They said “If you told me 1 year ago VB would one day have Generics I wouldn't have believed it”

I still prefer the syntax of C#. In a paste life I was a C developer so I am used the the sparse syntax and I like curly brackets. However, although I still find VB a bit verbose for my taste. I have been developing an application with it and it's a good language, VB.NET has a lot going for it.

WSDL and XSL

If this solution is familiar to experienced XSL users, forgive me.  I'm a casual XSL user, so the problem was difficult to identify and I didn't find much in the way of Google entries covering the answer.  So that (in my small, secluded little world) makes it blog-worthy.

The situation I found myself in was needing to convert the WSDL output from an ASP.NET page to a specific XML format.  The reason for the format is irrelevant.  Suffice it to say, that I needed to create a list of the valid SOAP operations for a particular web service.  I tool the WSDL that was generated by ASP.NET and started the trial and error process of identifying the correct XSL stylesheet to use.  This is where I ran into problems.

I do understand the basics of XPath enough to try simple queries.  My starting point was to list out the portTypes for the WSDL.  To do this, my initial XPath query was //definitions/portType.  This didn't actually return any nodes.  I thought this strange, so I dropped down to the more straightforward //definitions.  This too returned nothing.  Running out of drop-back room, I went with the wildcard //*.  Fortunately for what remains of my hair, this worked. So the question of why the other queries didn't work remained.

After more painful attempts (and a weekend to allow my brain some reset), I finally came across the solution.  XPath queries don't work with the empty namespace.  They require that the namespace be explicit within the query.  But the WSDL generated by ASP.NET does not assign a namespace to the WSDL elements, choosing to use the empty namespace.  So the XSL file needed to be modified to define a namespace for the URI associated with the WSDL elements.  When done, the xsl:stylesheet element looked like the following:

<xsl:stylesheet version="1.0"
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" >
 

The key here is the xmlns:wsdl attribute.  This defines a namespace called wsdl and associates it with the listed URI.  This URI needs to match exactly the URI associated with the empty namespace in the WSDL file.  And I do mean exactly.  Character for character.  Byte for byte. 

Once this has been added to the stylesheet tag, the XPath queries can be modified to be //wsdl:definitions/wsdl:portType and the results will be as expected.