Tone's Notes

ViEmu (from www.viemu.com ) brings vi style editing to Visual Studio.

In classic text editors such as Emacs and Vi it is a very simple operation to create a temporary macro to repeat complex editing sequences.

Remarkably, in Visual Studio 2005 it is still relatively hard to do this successfully. The general problem is that there are many commands which don’t record and playback accurately.

The key operation in creating many useful temporary macros is being able to use a variety of commands to locate the beginning and end of a selection. Holding down the shift key while using simple movement commands extends a selection but there’s no way to extend the selection when using Incremental Search (Ctrl-I) or regular Find (Ctrl-F). In these situations, the classic solution is to position a mark at the beginning of the selection, move to the end, and then set a selection between the mark and the active position.

Here are some simple macros that set a mark based on the current active position and set the selection range from that mark to the active position.

    Dim markPoint As EnvDTE.EditPoint

    Sub Mark()

        markPoint = DTE.ActiveDocument.Selection.ActivePoint.CreateEditPoint

    End Sub

    Sub SelectToMark()

        Dim selection As EnvDTE.TextSelection

        Dim activePoint As EnvDTE.EditPoint

        selection = DTE.ActiveDocument.Selection

        activePoint = selection.ActivePoint.CreateEditPoint

        selection.MoveToPoint(markPoint)

        selection.MoveToPoint(activePoint, True)

    End Sub

By assigning keyboard shortcuts to these two commands it is possible to create complex temporary macros that don’t require editing and which work on the first try.

There are a number of existing commands in the IDE which hint at this functionality but for which I haven’t been able to find a complete working scenario. The commands and the open issues are:

In a moment of clarity (and subsequently experimentally confirmed) Visual Studio 2005 project files are MSBuild build files.

I started off looking for a way to generate an equivalent MBBuild build file from a VS project file (.csproj).

This is mostly true, but not always true. Windows Forms application setup files are still ad-hoc syntax files that are not MSBuild friendly.

There’s a MSBuild based add-in for web deployment projects in Visual Studio 2005 available here.

I’ve seen a number of developers surprised by InvokeRequired returning false in situations when they know it’s a cross thread call.

The reason is that the underlying window handle associated with the control has not been created yet at the time of the call.

Since InvokeRequired is meant to be used with either BeginInvoke or just Invoke, and neither of these methods can succeed until a windows message pump gets associated with the control, it elects to return false.

There is some support for FTP in Whidbey beta 1, but it still failed my real world requirements.

Using both the FtpWebRequest / FtpWebResponse and WebClient classes failed to connect to an embedded system running an ftp server that Windows Explorer had no trouble connecting to.

I tried two third party FTP components for .NET (Mabry's FTP/NET and CSpot’s FTPComponent). Both components succeeded in connecting to the server when run as Visual Studio 2003 projects (using their own sample code). But both components failed (typically by hanging in the class constructors) when run after conversion to Visual Studio 2005 (Whidbey beta 1).

It seems that at the moment, there’s just enough FTP implementation in Whidbey to work with some FTP servers, but not all, and just enough changes to interfere with the existing crop of 3^rd party components.

The following notes apply to debugging an application running on a Windows XP SP2 box that is intended for stand alone deployment and does not want to (or is not able to) join the same domain as the development machine. The development machine is running Windows XP SP2 as well and is a member of a domain. These steps are known to work with Visual Studio 2005 beta 1 (Whidbey) and will probably also work with Visual Studio 2003.

The first problem you might run into is not being able to see the workgroup machine from the Visual StudioàDebugàAttach to ProcessàBrowse… dialog. Doing the following will cause the non-domain machine to begin advertising itself as a workgroup machine to other networked machines, including your domain development machine.

1. System control panel, Computer Name tab, Network ID button. Told the "Network Identification Wizard" that this computer is part of a business network that does not use a domain.

The next thing your likely to run into is an error dialog after selecting the workgroup machine from the Attach to ProcessàBrowse… dialog. There are a number of things that can prevent the connection from being made and the error dialog may or may not point you in the right direction. Another thing to try that can help get things configured is to run the Remote Debugging Monitor on the workgroup machine manually. It has some good diagnostics that it displays at startup if there are connection issues.

2. Run Visual Studio Remote Debugging Monitor (msvsmon.exe) which you may find under Visual Studio->Tools. Install Remote Debugging Support from the Visual Studio installation CD if you can’t find it.

One way to satisfy the authentication requirements when debugging a workgroup machine from a domain machine is to create a local account on the domain machine that matches the account being used on the workgroup machine. You may also need to modify the local security policy on the workgroup machine to prevent all remote accesses from mapping to the guest account.

3. Run Administrative Tools, Local Security Policy and configured Local Policies->Security Options->Network access: Sharing and security model... from "Guest only" to "Classic". This keeps all remote access authentications from mapping to the guest account.
4. Created a local account on development (domain) machine to match local account on the workgroup machine (the machine being debugged). Add account to administrators group. Add access to the source tree to the account.
5. Run Visual Studio as the local account.
6. Open the project/solution.
7. Run the application on the workgroup machine.
8. Attach to the process from the domain machine: DebugàAttach to Process

The solution task was failing with a 403 error looking up webmap map entries until the casing on the url was matched to the casing in the solution file (.sln). Since the solution file’s casing is arbitrary (whatever you typed in when you added the project), this isn’t the right behavior.

Error checking whether 'http://localhost/virtualdirectory/root.csproj' is an enterprise template project.

 The remote server returned an error: (403) Forbidden.

A second bug appears to be Microsoft’s, a .csproj <File> element with a RelPath attribute value containing an ampersand causes a NAnt solution task error of

An error occurred while parsing EntityName.

The ampersand should have been converted to an entity reference of &amp;. That makes NAnt happy, but breaks Visual Studio. We’re not quite all there yet with XML are we….