Attach to Debugger shortcut in Visual Studio

We've been doing some bug fixing this week and have ended up creating a new plug-in, so to ease the debugging pain, I have used some post build actions to deploy the plug-in while debugging, see this post for more details. The one thing that I hadn't automated was attaching to the debugger, which while not very time consuming it was starting to grate me a little bit, particularly after I mistyped a property name twice in a row.

So after a bit of googling I found this and this, which I have combined into this post. Note that I've used VS 2008, but this should work in VS 2010, just need to add import EnvDTE100 to the macro, I haven't tried it though.

In Visual Studio go to:

1. Tools |  Macros | Macro Explorer 
2. Right Click MyMacros | New Module
3. Name it AttachDebugger
4. Double Click on Attach Debugger to open the Editor.
5. Paste the code below:

Option Strict Off
Option Explicit Off
Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports System.Diagnostics
Public Module AttachDebugger
    Sub W3WP()
        Try
            DTE.Debugger.DetachAll()
            For Each proc As EnvDTE.Process In DTE.Debugger.LocalProcesses
              If proc.Name.IndexOf("w3wp.exe") <> -1 Then
                    proc.Attach()
                End If
            Next
        Catch ex As System.Exception
            MsgBox(ex.Message)
        End Try
    End Sub
End Module

6. Save it.
7. To add the Shortcut, now go to Tools | Options | Environment | Keyboard 
8. Type W3WP and enter your shortcut

9. Click Assign and off you go.

If you are deploying asynchronous plugins as well, you could create another Sub that attaches to the asynchronous service  and simply give it another shortcut.

Post-Build actions in Visual Studio

I've been working on sorting out some issues with a plug-in in one of our applications. It all started easy enough with me thinking that a few tweaks here and there would be enough, but it has ended up being a bit of a mess and all the malarky needed to register the plug-in and copying it to the assembly directory to enable debugging, well it gets tiring quickly, so I thought I had better automate it.

To be honest, I've never had a look at build actions before, so I wasn't sure whether it was worth the effort. You know how it is, you can do something manually and it will take you 1 hour of tedious work or you can learn a better way of doing it or you can write and app/script that will take you a few hours to write. Normally I favour the latter approach, as you always learn something, even if it is that sometimes it is better to bite the bullet and do it the long way.

At any rate, I wanted to copy the plug-in library to the assembly folder only for debug builds and it turns out that this is easily done, like so:

if $(ConfigurationName) == Debug (
copy /Y "$(TargetDir)plugin.dll" "C:\inetpub\wwwroot\isv\cbs\bin\plugins.dll"
copy /Y "$(TargetDir)plugin.pdb" "C:\inetpub\wwwroot\isv\cbs\bin\plugins.pdb"
)

Make sure that the first bracket follows on the same line as Debug

This can actually be improved by doing the import at the same time as well. Starting from an already deployed plug-in (I know, I know, catch 22):

1. Open the PluginRegistrationTool and open the organization you want to update plug-ins from.
2. Hit Import/Export Button.
3. Select Export Solution Xml
4. Ensure that you only select your custom plug-ins.
5. Save this to your build directory (You can save it anywhere, but it'll save you typing if you use the build directory, .e.g $(TargetDir) ).
6. Copy the PluginRegistrationTool to your build directory (This is optional as well, but bear in mind that you will need to provide a path to the executable otherwise).
7. Copy the connections.config file to your build directory.

In order to make my life easier, my user is a deployment and system administrator, so that I can leave the credentials empty and it will use my credentials. I've not managed to get it working with different credentials.

if $(ConfigurationName) == Debug (
copy /Y "$(TargetDir)plugins.dll" "C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly\plugins.dll"
copy /Y "$(TargetDir)plugins.pdb" "C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly\plugins.pdb"
PluginRegistration.exe /org:CDCC /op:import /f:ExportSolution.xml  /c:Connections.config /cl:DEBUG
)

Where CDCC is my org and DEBUG is the label on the connections.config file

Unfortunately, sometimes it seems that an iisreset is needed for the plug-ins to be picked up properly, so it might be advisable to add an iisreset command too.

The importance of good references

As part of the housekeeping service that I was talking about yesterday there is a call to the CrmService.Delete method.

Having gone through the pain described in my previous post,or not, as it doesn't tell anything about all the hair pulling,  code revisions, swearing, etc.. Anyway I ran into another issue: The DeleteMethod, that wasn't described in my previous post, is simply a wrap around for the CrmService.Delete method and whenever I passed the entity name and a guid I would get this error:

DeleteEntity web service method name is not valid

I checked the entity in the database and it was there. I checked the CRM trace logs and found nothing, which I thought it was a bit strange. I added a catch block for SOAP Exceptions and found that it wasn't a SOAP exception. I refreshed the web service references in the Visual Studio project, but to no avail. 

A colleague suggested removing the references and readding them and this fixed the issue, WTF???. This is the second such incident (CRM service reference issue that I have had) and have solved both the same way, i.e. by removing the references, web service references I should say, and re adding it, but never really understood what the cause of the issue was. At any rate, maybe it'll help somebody if they come across the same issue as me.