by Gustaf Westerlund | Dec 20, 2007
Finally CRM 4.0 has been released to manufacturing (RTM) and trial versions can be downloaded here: http://www.microsoft.com/downloads/details.aspx?FamilyID=a9c110fd-aac8-4d2a-b401-7801b1866e82&DisplayLang=en
I would also like to point out that there are (at least) three different media types in general released from Microsoft.
MSDN – Can use MSDN or Trial keys.
Normal – Can use Trial or “Normal” license keys.
Volume Licence – Can only use volume license keys. If you want a trial, use it for a maximum of 90 days and uninstall it.
This is important when installing a trial environment that might be upgraded to production environment in the future at a customer. Consideration has to be taken to their current license agreement with Microsoft, and you can never use the MSDN media to install a production server.
There might be exceptions to this rule, for instance, a MSDN media might accept a normal license key, but I would not expect it.
Gustaf Westerlund
Microsoft Dynamics CRM Consultant
WM-Data/Logica CMG
www.logicacmg.com
by Gustaf Westerlund | Dec 7, 2007
I have been developing a front-end user GUI for a product configurator as a normal aspx-page. I started the development localy and then moved the project to our development server in a virtual directory bellow the CRM directory. (Please read earlier posts concerning problems with this and how to handle it) This is an unsupported way of placing your custom aspx-pages, but the disadvantages of doing it any other way are to great.
Well, my code used ViewState to store some data between requests and this had worked fine on my local machine. But, when I moved it to the virtual directory bellow the CRM site, the ViewState handling stopped. I tried to override the LoadViewState-method but it was never fired. I tried to explicitly set the page to have the property EnableViewState = true, but that didn’t help either.
Then I remembered some things about how settings are inherited from the master website to all virtual directories bellow (i.e. the web.config settings are inherited). This is the reason for why you have to add some <remove assembly=”…”>tags to the virtual directory’s web.config when deploying bellow the CRM website.
I thought that there might be some swith in the CRM web.config that disabled the ViewState and there was; the tag I found was the following:
<pages buffer=”true” enablesessionstate=”false” enableviewstate=”false” validaterequest=”false”>
So, I copied the entire tag to the web.config in the virtual directory, changed enableviewstate=”true” and magic, it worked!
So, specific advice: This is why viewstate might not be working in a Virtual Directory bellow the CRM site.
General advice: All settings in a websites web.config are automatically inherited to all virtual directories bellow. If you want to change anything, set this explictly in a local copy of web.config.
Over and out.
Gustaf Westerlund
Microsoft Dynamics CRM Consultant
WM-Data/Logica CMG
www.logicacmg.com
by Gustaf Westerlund | Nov 30, 2007
SOAP is a great thing, not only does it get you clean, but it is also the foundation for most modern webservice communication. It is supposed to be platform independent.
A good thought but does, however, seem to have it’s limitation. To be able to thoroughly understand the communication between the client and webservice a good program is needed that can help you study how the web service works and how the SOAP-messages are sent and received.
When working in a .NET environment, a .NET based client is very advantageous and a business partner of mine at the company Lemontree, Oskar Mattsson, suggested a very good application. I havn’t had time to try it out fully yet, but it is also a GotDotNet-project so you can also read the code of how it is doing it’s calls.
The name of the program is WebServiceStudio 2.0 and you can download it here:
here
Gustaf Westerlund
Microsoft Dynamics CRM Consultant
WM-Data/Logica CMG
www.logicacmg.com
by Gustaf Westerlund | Nov 29, 2007
My colleague Daniel Westerblom at WM-Data asked my a question concerning the fake lookups that I have referenced bellow and that I know are commonly used by many partners. The question was if these customizations are supported.
When I was at convergence I asked this explicit question to, I think it was, Clint Warriner (CRM Escalation Engineer at Microsoft Support) and he gave me confirmation on what I had suspected, that these customizations are not supported. They fall under the last point concerning unsupported customizations described in the SDK:
“The use of custom HttpModules to inject HTML/DHTML into the Microsoft CRM Forms.”
Since the HTML DOM is modified, this is not supported.
The reason for this is most probably that Microsoft might choose to change this in future releases of CRM (for instance CRM 4.0) and might also have internal scripting references to objects they expect to be there according to the standard HTML DOM.
I don’t know if these fake lookups will upgrade from CRM 3.0 to 4.0 without problems. If you have any experience of it, please let me know.
If you have any comments on this subject, please feel free to comment bellow. I always publish comments that concern the subject and are not directly offensive. (I have activeted moderation on comments just to avoid comment spamming).
Gustaf Westerlund
Microsoft Dynamics CRM Consultant
WM-Data/Logica CMG
www.logicacmg.com
by Gustaf Westerlund | Nov 29, 2007
Usually I develop on a CRM server but sometimes, when a larger piece of CRM-independent part needs to be developed, I develop on my local machine.
Presently I am working in an integration project with an integration engine and needed to consume one of it’s webservices. I did so and I added some code to handle it (intellisense working fine) but when I tried to run it, it crashed on the constructor or the service class with the following error:
System.IO.FileNotFoundException: File or assembly name gvy6umsk.dll, or one
of its dependencies, was not found.
There was also a reference to the WindowsTemp-directory. The filename is obviously some temporary filename for the proxy-object.
After checking the web a bit, I found the error to be caused by the fact that the user running the software, did not have read/write access to the c:windowstemp directory. I fixed it and the program ran like it should!
So, if you are in the same situation, just fix the right for the windowstemp directory and you should be fine.
Gustaf Westerlund
Microsoft Dynamics CRM Consultant
WM-Data/Logica CMG
www.logicacmg.com
Recent Comments