I updated the utility exports to disk the JavaScript found in a solution in Dynamics CRM 2011. To read more about it, see the original announcement, found here.
This updated fixes some issues where the JavaScript would not be exported depending upon the solution you selected and the solution you chose to export. ( it was basically a design-flaw on my part. )
If you are running IFD using ADFS to access your CRM system, then you may be unable to connect to CRM. If you receive a 401 error, then please let me know. I am currently working with Microsoft to determine a course of action around this issue.
Otherwise, if you find any issues, then please let me know.
I've corrected some issues I found with the utility that allows you to look up User and Privilege information by ID:
You my find it on my Free Utilities page.
Dennis Michalis, Microsoft Dynamics General Manager, released the roadmap for the upcoming Q2 2012 release of Dynamics CRM 2011, which they are calling R8. Read more about it here.
The actual roadmap document can be found here.
Looks like we're in for some exciting times this year!
We have released a small update to the CRM Migration Assistant which includes the following updates:
- Added 0 and 1 as supported Submit Options
- Fixed issues with converting .AddOption to .addOption method.
- Conversion alerts were added for the following JavaScript properties:
- .title
- .vAlign
- .contentEditable
- .innerText
- Any .style property that is not either display or visible is now marked as a conversion issue. This is to help identify instances where people have created unsupported code which will probably not work within the CRM 2011 environment.
- The use of document.all.mnuBar1 now produces a conversion alert.
- Instances of the DOM element 'Notifications' will cause a conversion alert will be generated. This is a special CRM form element at the top of each data entry form that shows alerts to the user. For more information on using this technique, see this article.
You may download the new package here.
If you ever need to move a virtual machine from Virtual PC to Virtual Server, you need to uninstall the Integration Services before you attempt to connect it to Virtual Server.
Each product has their own version and they are not compatible.
Also, once the VM is up and running in Virtual Server, you can't uninstall the Virtual PC Integration Services ( at least I've never been able to find a way ).
Note: There may be tools that do this, but I'm not aware of any. So if you know something I don't please put a comment on this article.
Finally, make sure you consolidate any snapshot images and do a clean reboot and final shutdown before you begin your move.
You'll be much happier in the long run.
HI Everyone,
If you have not heard, Dynamics CRM 2011 will very shortly support browsers other than Internet Explorer.
I am absolutely unsure if this is a big deal for customers or not. So, I thought I'd ask.
I've created a poll on my site that allows you to select which browsers you will be using. If you have some time, I'd appreciate the feedback.
You can also leave a comment on this post.
Thanks, Mitch
When working with things like Email, it is sometimes necessary to decode a string of text that has been HTML-encoded. This is the process where special characters are replaced with their numerical equivalents to prevent misinterpretation of the HTML text.
You use it like this:
string xmlPacket = HttpUtility.HtmlDecode(input);
This method is found inside of System.Web, which seems to require full trust to run properly.
Since I'm running in the sandbox, I can only use partial trust assemblies.
Thankfully, the System.Net assembly has: WebUtility.HtmlDecode, which works exactly the same AND doesn't cause us security issues.
One of the most fascinating things I found during the creation of the CRM Migration Assistant is the different methods developers use to access CRM form fields, and other form elements.
Normally, people access a form field using the following style of JavaScript:
crmForm.all.name
This is the normal and perfectly acceptable (and supported) method for referencing CRM form fields.
But, for various reasons, I've also seen fields reference using these crmForm methods:
crmForm.name
crmForm.elements["name"]
crmForm.all["name"]
crmForm["name"]
This is perfectly acceptable JavaScript and the CRM 4.0 object model had no objection to this practice, so all of these methods seemed to work.
In fact, accessing CRM form fields using the JavaScript document object using these methods worked as well:
document.all("name_c")
document.all["name"]
document.getElementById("name_c")
The real question is: Will these methods continue to work when the organization is upgraded to CRM 2011?
The answer is: If you have used standard and supported methods within your JavaScript, then yes, the code will be supported.
This means referencing all of your form fields using the standard access model:
crmForm.all.name
Other options may or may not work correctly. Your experience my vary depending on which of the above methods were used.
Fortunately, the CRM Migration Assistant converts all of these "unsupported" form field access types into fully-supported CRM 2011 code using Xrm.Page.getAttribute and Xrm.Page.getControl, depending on how the field was being used.
If you haven't already, download the trial version of the CRM Migration Assistant and convert some of your questionable JavaScript through the conversion process.
If you run into any conversion issues, send me a code sample so that I can update the conversion process.
I learned some interesting things about working with Sandboxed plugins last week that I thought I'd share.
Attaching to Processes
Sandboxed plugins are run by Microsoft.Crm.Sandbox.WorkerProcess.exe so that is the process that you will need to attach to in order to debug your plugin. If there are more than one, then attach to all of them.
If there are none active in memory, perform whatever process that activates your plugin and the Sandbox HostService will activate at least one. Then you can attach to them.
If you are running a sandboxed plugin with an asynchronous step, you will also need to attach to CrmAsyncService.exe since this process is involved as well. More on that in a minute.
Using the Debugger
The Sandbox HostService only allows the WorkerProcess to process for 30 seconds. If it runs longer, it is terminated. This is a real problem when you're trying to look at data within the debugger and your code and data disappears in front of your eyes.
Add a DWORD key called SandboxDebugPlugins with a value of 1 to the MSCRM registry to prevent the process from being abnormally terminated.
Asynchronous Plugin Steps
A very interesting factoid is that if you have an asynchronous step inside of the sandbox plug, the processing of the step is different:
The CrmAsyncService.exe process will run your asynchronous step as it would any other async process but since it is from a sandboxed plugin, it will actually hand your plugin to the Sandbox process for execution.
This is why you must attach to both the Microsoft.Crm.Sandbox.WorkerProcess.exe and CrmAsyncService.exe in order to get the Visual Studio debugger to launch.
More Information
See this topic in the CRM SDK for more information.
One of the things that gets CRM 4.0 developers into trouble is moving customizations between organizations. Here is a tip that will prevent a lot of grief trying to troubleshoot some of the more confusing errors:
Always, Always, Always export all of your customizations from the source environment.
You can always import only the items that you are working on. The Import Customizations page allows you to select the items being imported.
Using this technique gives CRM all of the information about your customizations and schema so it it needs some secret little part of something, it is available.
Sometimes it will miss data or other relevant information and while not producing an error, may not fully recreate the customizations as you defined them within the source environment.
I have seen this appear as lost icons, invalid relationship connections, and just plain strange stuff that takes hours to find and fix.
An Example:
Last year, I ran into such a situation where we could not Publish All Customizations.
It took me about 6 hours to find and fix but the problem was related to a custom entity that was, well, broken. I had to manually insert a record into the database to fix it. ( and yes, that scared the crap out of me. )
It is my firm belief that this occurred because the person who installed the customizations only moved the four entities required from one organization to the other.
My initial solution was to export all customizations from the original source organization, import only those four entities into the development environment, then finish the remainder of the database cleanup manually.
This process had to be duplicated to the test and production organizations as well.
All in all, not a fun time and one that stretched my personal and professional expertise to the limit.
Loading ...
