Workflow activity development and file locking

As some of you might have noticed, the dll:s containing the custom workflow activities might get locked and hence the compilation fails in it’s final stage.

To handle this, I tried a good program called Unlocker 1.8.7 which you can find here: http://ccollomb.free.fr/unlocker/ – it is freeware and it will tell you which processes are locking a file and can help you kill them.

So, what is locking my dll? Well, actually several processes are involved both the MSCRMAsyncService and the IIS worker process (w3wp).

The most obvious way of handling it is just restarting the two services and that will work. However, restarting the w3wp process will require the entire CRM application to be recompiled which will create extra long and annoying waits. Instead, just recycle the applicationpool involved (CRMAppPool).

There are no problems restarting the MSCRMAsyncService.

And if you want to do it all in the pre-build event just add the following lines:

net stop “MSCRMAsyncService”
net start “MSCRMAsyncService”
cscript C:InetpubAdminScriptsadsutil.vbs stop_server W3svc/AppPools/CRMAppPool cscript C:InetpubAdminScriptsadsutil.vbs start_server W3svc/AppPools/CRMAppPool

And if you are still having problems, use the unlocker program!

Gustaf Westerlund
Microsoft Dynamics CRM Architect

Logica
www.logica.com

List Web Part for Dynamics CRM 4.0

Finally Microsoft have release the List Web Part for Dynamics CRM 4.0. I havn’t had the opportunity to test it yet but the previous version (for CRM 3) had problems with non-english versions of SharePoint so be aware, especially if you are running CRM and SharePoint in different base languages.

If you have any experience of it, please let me know.

Gustaf Westerlund
Microsoft Dynamics CRM Architect

Logica
www.logica.com

AT&T Wireless self destructs…

It’s actually an old story by now but I just recently heard of it from my new staff manager and it is a very interesting story of just how bad a CRM implementation can get. It concerns Siebel and my analysis of the story is that the reson for the crash was mostly due to bad management and a lock on both timeframe and functionallity, something I believe is impossible if you want to achieve any kind of quality. This case being the perfect example.

Please read it and leave a comment here if you want to discuss it!
http://www.cio.com/article/32228/Project_Management_AT_T_Wireless_Self_Destructs

Gustaf Westerlund
Microsoft Dynamics CRM Architect

Logica
www.logica.com

Putting all javascript code in external files

Dynamics CRM is great. It has some really nice functions like being able to add javascripts to different event in the form to handle special needs of the GUI.

However, it is only fine as long as these scripts arn’t that many and not too complex. When they start getting more and more complex, bigger and their numbers start increasing it soon becomes an impossible tast of maintaining them all and there is no built in function to handle javascript includes without special code. It also takes a long time developing more complex code in the javascript form window in CRM and then running the preview or publishing it each time before testing.

There is light in the tunnel however, by using the technique specified bellow, you can both
get global javascript files, save and refresh only to see you changes, and keeping all scripts for one entity in one file (and not one for onLoad, one for onSave and one for each onChange that is needed).

A lot of credit for this has to go to Michael Höhne at Stunnware since he added a posting on his blog on how to manage javascript includes in runtime.

So, first of all we have to put some standard code in the onLoad. This should only be done once and it shouldn’t really be changed until you need to publish it for release (switching of the caching).

var LoadFile = function(url, cache)
{
var httpRequest = new ActiveXObject(“Msxml2.XMLHTTP”);
httpRequest.open(“GET”, url, false);
if (!cache)

{
httpRequest.setRequestHeader(“If-Modified-Since”, “Sat, 1 Jan 2000 00:00:00 GMT”);
}

httpRequest.send(null);
return httpRequest.responseText;
}

eval(LoadFile(“/isv/mycrmext/javascripts/MyGlobal.js”, false));
eval(LoadFile(“/isv/mycrmext/javascripts/Account_onload.js”, false));

This code simply loads and executes the two files MyGlobal.js and Account_onload.js located in the directory C:Program FilesMicrosoft Dynamics CRMCRMWebISVmyCRMEXTJavaScripts
and can be found at the url: :port/isv/mycrmext/javascripts/”>http://:port/isv/mycrmext/javascripts/.

So, copy-paste it into the onload event form in the account form editor in CRM. Activate the event, save and publish.

Then you can create the two .js-files at the specified directory. Start with just some test code like:
alert(“This is the MyGlobal.js-file”);
or something similar.

The next step is to try to avoid using the onsave and onchange events. This is quite easy when you know how but it is sort of in the gray area of supported customizations so be aware of this.

In the file Account_onload.js add the following code:
var MyOnSave = function()
{
alert(“onSave”);
}

var MyOnChange = function()
{
alert(“onChange”);
}


alert(“onload)

crmForm.attachEvent(“onsave”, MyOnSave);
crmForm.all.name(“onchange”, MyOnChange);

This attaches a simple function to the onsave event of the form and another to the onchange event of the attribute “name”.

The functional defintions/declarations can be put into any of the includefiles.

Now, just save the file, and open an account to see the magic! (It should show a dialog when loading with the text “onload”, when the accountname is changed, it should show “onchange” and when saved, it should show “onsave”.

Please note that I would advise you to put the javascript files in the same “host” from a IE perspective since you will get less problems with cross domain scripting and similar IE related security issues. This doesn’t however mean that you cannot put the js-files anywhere on the internet where the clients can access it.

Gustaf Westerlund
Microsoft Dynamics CRM Architect

Logica
www.logica.com