The Mail Owl Scrolls

Just a quick post,  I stumbled upon some CRM Webcasts on the Microsoft website.  I'm busy listening to Extending and Integrating with MBS CRM by Jason Hunt and so far it's been quite good.

powered by IMHO 1.2

So, after working with .NET for so long, it has finally caught me out and thrust me into “Config Hell”.

I’ve been having a problem of my dropdownlists not persisting data when I dynamically populate them at run-time.  I could populate and select an option, but when the page did a post-back, not only was there no selected value, but the dropdownlist was empty.

I couldn’t figure out what was wrong.  I knew it had to be the viewstate, but I couldn’t figure out where I had turned it off.  After 2 days of battling I gave up and went home to enjoy the weekend.

Sunday saw me sleeping in, and stressing about how to work around this problem.  Eventually I had an idea.  I remembered reading somewhere that the sessionstate of CRM was off by default (for security reasons); I wondered if it was possible that the viewstate was off by default too.  Excitedly, I hurried to the office and searched the CRM config files.

I quickly found what I was looking for.  In the web.config file in the root of the CRM website is a <pages> tag with the attribute enableViewState and it was set to false!  Suddenly, after changing it, my dropdownlists were persisting data.

So, you have been warned!

What stumped me earlier was that I was dynamically populating listboxes in dialog windows and they were working perfectly.  But, in truth, I was never doing a post-back; I was reading the selected value on the client-side.

There is one question for the CRM team though.  How is the CRM website affected by the <pages> tag?  I can’t believe that they’re not making use of sessionstates and viewstates.

powered by IMHO 1.2

I was really interested in this article from page 10 of the Cape Argus, going over what Mbeki promised in his 2004 State of the Nation address and what has, so far, been delivered.

Personally I think Mbeki is doing an overall good job of balancing the expectations of the many bigoted groups in South Africa, using peaceful diplomacy with tyrannical and sanguineous African leaders and placating demanding European and American interests and still getting results that improve ordinary people's lives.

While I'm not a tie-dye t-shirt wearing, hippie activist, nor a political brown-noser, whimping out as an oppressed minority; I firmly believe in supporting those people with the power to make a positive difference in my country.

powered by IMHO 1.2

May the gods of CRM and Best Practices forgive me; for I am debugging in my live CRM environment. *begins to flagellate* (look up the meaning before you laugh)

At least now I can remotely debug, putting my custom CRM development in the CRM’s application pool and giving me access to the user identity and other session variables.  It’s taken me roughly 3 days so in total my project is 9 days behind!

So with my sins forgiven and my anguish dulled, here’s how you setup remote debugging.  My client machine (the machine I’m developing on) is running Windows XP with Service Pack 2 and the server is running Windows 2003.  Lastly, I’m developing using Visual Studios 2003.

Setting up Remote Debugging on the server

Insert the Visual Studio .NET 2003 Disc 1

1. Don’t bother with clicking on Remote Components Setup; the links are a bit buggy.
2. Instead explore the CD and find RemoteComponents.htm
3. You need to install Visual Studio Analyser Server and Full Remote Debugging.  Search the html document and you’ll find the paths to run.  They look something like this:
   1. msiexec /qb+ /i d:\vs_setup.msi NOVSUI=1 TRANSFORMS="d:\Setup\Rmt9x.mst" SERVER_SETUP=1 ADDLOCAL=Visual_Studio_Analyzer_Server11
   2. msiexec /qb+ /i d:\vs_setup.msi NOVSUI=1 TRANSFORMS="d:\Setup\Rmt9x.mst" SERVER_SETUP=1 ADDLOCAL=Full_Remote_Debugging
   3. On the Start menu, choose Run. Type the first path in and run it.  Then run the second.

    

   Congratulations you’ve setup Remote Debugging on the server.  Now we move on to the more important task of setting up the client machine.

    

   Setting up Access for Remote Debugging on the client

    

   1. Download debuggerfirewallconfiguration.exe from Microsoft and run it.  This sets up the Windows XP firewall to allow the remote debugging protocols through.
   2. On the Start menu, choose Run.  Type DCOMCNFG
   3. Expand Component Services.  Expand Computes.  Right-click on My Computer, choose Properties.
   4. Click on the COM Security Tab.  Click on Edit Limits in the Access Permissions frame.  Select ANONYMOUS LOGON and tick Allow for Remote Access.
   5. Restart the machine.  You have to do this, I’m sure you could restart a service, but I’m not sure which one.

    

   Again Congratulations, you are now ready to begin remote debugging.  Open Visual Studio and create a new ASP.NET Web Application.  In the location make sure to change the hostname to the server name. For example

    

   http://crm/WebApplication1

   Side Note: I couldn’t figure out how to provide a username and password when setting up the website, I’m assuming that it uses the user that you are logged in with on the client machine.  Combine this with CRM using Windows Integration security and your client machine HAS to be on the same domain as the server.  So my attempt to setup a stand-alone test server and have my client still on the network falls flat on its face.

    

   Happy debugging!