Thankfully with the help of FiddlerCore, this was not that difficult of a problem to solve. I took some inspiration from LiveReload and wrote a WPF wrapper around FiddlerCore which I lovingly call Imposter.
Imposter allows you to create a profile that contains a couple of basic settings including a base URL or URL fragment to match requests on and a working directory from which local files will be proxied for remotely requested resources.
Another great feature is that Imposter can be set to automatically refresh any HTML page that is able to be proxied whenever a file in your working directory changes!
Let’s use some scenarios to clarify the behavior. Say your settings are:
Here’s what Imposter will do in the following scenarios:
- Browser requests file: http://awesome/index.html
- Imposter looks for C:\source\awesome.web\index.html and if found, serves that file to the browser instead of the remotely hosted file.
- Browser requests file: http://awesome/js/index.js
- Imposter looks for C:\source\awesome.web\js\index.js and if found, serves that file to the browser instead of the remotely hosted file.
- Browser requests file: http://notsoawesome/
- Imposter ignores the request.
So you can see that Imposter has a fairly simple set of rules that it follows by default. I just today added in another profile setting for overriding the default “match this path and file name” rule so that you can serve up files that may not match the default rule. The ability to override the default behavior is especially handy for when your directory structure doesn’t match your deployment structure, or if you want to serve up an unminified file temporarily for debugging purposes.
The only real gotcha is that since Imposter uses FiddlerCore, you can’t run Fiddler at the same time. I see this as a minor problem though and one where the positives greatly outweigh the negatives.
If you want to check out the tool, feel free to grab it or its source code over at http://github.com/gotdibbs/Imposter and feel free to comment or provide feature suggestions!
Posted: June 3rd, 2013
, General Technology
, MSCRM 2011
, CRM 2011
, Dynamics CRM
Comments: 3 Comments
I recently found myself getting pretty annoyed when working from home. Why? When I needed to go join a Lync meeting, I’d have to copy the URL from Outlook on my remote desktop session, paste it into a new IE window on my home computer and then wait for it to close IE and open the Lync meeting. Suffice it to say, it was complicated and annoying. Did I mention annoying?
After a bit of meddling around in the Lync SDK, I scrapped that idea and instead hooked the app straight up to Exchange Web Services. From here it was actually pretty darn simple to flesh out.
The end result is this beautiful application below. The instructions for installation and usage are included on the GitHub page for the project, which is located here: https://github.com/gotdibbs/Meetings/. Feel free to download, modify, or redistribute at will – but let me know if you have any feedback!
Posted: May 2nd, 2013
, General Technology
, Exchange Web Services
, Upcoming Meetings
Comments: No Comments
If you’ve spent a significant amount of time developing plugins for CRM 2011, then you’ve most likely at one point or another run into the error message “Assembly must be registered in isolation”. Whether that occurs when using the Plugin Registration Tool from the SDK, or during import of a solution.
Most of the time this error boils down to one of two problems. I just this week encountered a third cause of this problem which I will explain later in this post.
Nine times out of ten the problem is that the user attempting to import the solution or register plugins manually is not a Deployment Administrator. To clarify, this is something that needs to be setup outside your actual instance of CRM. It is not just another security role or permission needing to be attached to your user record in CRM. Instead you must add the user via the Deployment Manager utility. If you need more detail on that, please leave a comment and I can clarify.
You may also see this error if you are attempting to register plugins outside the sandbox in CRM Online. Since CRM Online requires that you register your plugins in the sandbox, there is no real way around this besides updating the solution you’re trying to import to have the plugins registered in the sandbox, or to mark them as sandboxed when using the Plugin Registration Tool.
Considering the frequency of this error, and the amount of articles available elsewhere on the internets about the issue, one would assume that those are the only two causes of this error message. However, we encountered an odd problem which also causes this behavior. If the user registering plugins or installing the solution has their username specified in CRM as user [at] domain [dot] local, and in Deployment Manager the user listed as a Deployment Administrator differently as domain\user, the same result occurs as if the user has not been added as a Deployment Administrator. To me this sounds like a bug, but thankfully there is a quick fix. All you need to do is update the user’s record in CRM to specify the username the exact same way as it shows up in the Deployment Manager utility. Boom. Back in business.
I am reposting my Sonoma Partners blog post from yesterday, hope you find it useful!
Just the other day a coworker and I were attempting to track down a request to CRM 2011’s OData service from Silverlight that just would not complete. We first noticed that a very simple update request was taking forever to finish and assumed there must be some sort of error happening that was not bubbling up through the user interface. We went down a long path to troubleshoot this issue, and this is our tale.
We started by first opening up Fiddler to check and see if there was actually an error occurring and it wasn’t bubbling up correctly. We’ve previously covered using Fiddler to help with troubleshooting problems in CRM, and you can reference that here (http://blog.sonomapartners.com/2012/01/fiddling-with-crm.html). However, we sat and watched the request, and it just never completed, just as it looked in the UI.
This was really strange as one would assume that the request would eventually time out; but today this was not the case.
For our next step, we headed over to the CRM Web Server to check its Event Viewer for any sign of error or warning occurring around the time of the request. While there was not anything explicitly listed in the Event Viewer, we did end up finding an event around that time. When we looked at the attached log, we found a detailed error stating: “Generic SQL Error”.
If you ever find yourself faced with a “Generic SQL Error”, it is far better to start with a SQL trace directly on the database as opposed to a CRM trace. Conceptually this makes sense as the error itself is actually occurring in the database.
We ended up heading off for the SQL Profiler in order to run a trace against the database. This can be done following the steps below.
1. Open the SQL Server Profiler. This can be found in the start menu under Microsoft SQL Server 2008 –> Performance Tools.
2. Select File –> New Trace.
3. Connect to the SQL Server in question.
4. On this screen’s General tab you can enter a name for the trace if you desire, and use a template if you have created one previously. Note that these instructions assume that you do not have a template setup already.
5. Go to the Events Selection tab.
6. Here you can start to select the events you would like to monitor. Filtering this down and checking individual events one at a time will help you be able to better hone in on your problem, but for now, we’ll select a bunch of events that are relevant.Note that for each event, if you check the box on the far left, the profiler will automatically select all the other columns on the right. Below you will find some suggested events from each category to monitor
a. Errors and Warnings: Exception, User Error Message.
b. Stored Procedures: RPC Completed, SP:StmtCompleted, SP:StmtStarting.
c. Locks: Lock:Deadlock, Lock:Deadlock Chain, Lock:Timeout, Lock:Timeout (timeout > 0).
d. TSQL: SQL:StmtCompleted, SQL:StmtStarting.
7. After selecting all your desired events to monitor, select the Column Filters button in the lower right hand corner of the window.
8. In the Column Filters window, select DatabaseName from the list on the left, and under Like enter the name of the desired CRM Organization’s database to be monitored. Performing this step will make sure you are only monitoring the data that is relevant to what you’re trying to troubleshoot.
9. Next you can click OK to get out of the Column Filters window.
10. Before you actually click Run to start the trace, you want to make sure you’re setup to reproduce the error message. Once ready, click Run in the SQL Server Profiler, then perform the action in CRM that causes the error. You will be able to Start, Pause, and Stop the trace from the toolbar in the main window of SQL Server Profiler.
We were able to monitor the errors and watch them happen during the trace. From here we were able to correlate what was being logged and determine that there was a process that was still running that held a lock on the table we were trying to access. We found a Lock:Timeout (http://msdn.microsoft.com/en-us/library/ms189107.aspx) event in the trace and this lead us to the fact that, as the event indicates, there was a process currently running that had a lock on the table and was causing our OData queries from Silverlight to fail.
Fair warning here that these methodologies were used on a development environment, and thus data integrity was not a huge concern. These methods should be used with caution and should be thoroughly evaluated by all parties involved before applying to a production environment.
After running a simple query we were able to verify that a query did have a lock on the table and had been running for several hours. Since we knew the table we were looking at did not have any long running processes that should’ve been occurring, we knew we could kill the process. After we killed the process, things thankfully returned to normal. We followed the following steps to retrieve that currently running process and then to kill it.
1. Open SQL Server Management Studio.
2. Connect to the SQL Server in question.
3. Create a new Query.
4. Execute the SQL statement below to display a list of all currently running transactions.
5. If you encounter a long running transaction that you’d like to end, just run a new statement, “KILL [sessionId]”, where [sessionId] is the Numeric identifier of the session you’d like to end.
SELECT TOP 100
[request_start_time] = s.[last_request_start_time],
[current_time] = CURRENT_TIMESTAMP,
[estimated_finish_time] = DATEADD
current_command = SUBSTRING
COALESCE(NULLIF(r.[statement_end_offset], -1)/2, 2147483647)
module = COALESCE(QUOTENAME(OBJECT_SCHEMA_NAME(t.[objectid], t.[dbid]))
+ '.' + QUOTENAME(OBJECT_NAME(t.[objectid], t.[dbid])), '<ad hoc>'),
[status] = UPPER(s.[status])
sys.dm_exec_connections AS c
sys.dm_exec_sessions AS s
ON c.session_id = s.session_id
LEFT OUTER JOIN
sys.dm_exec_requests AS r
ON r.[session_id] = s.[session_id]
sys.dm_exec_sql_text(r.[sql_handle]) AS t
s.status like '%running%'
ORDER BY session_id desc
While we weren’t able to uncover why that process had never completed, we were at least able to end the process, and we haven’t had the problem since.
So this problem has been bothering me for months and being the busy guy I am, I’ve ignored it as it was a small annoyance until this weekend. In the morning, I’d put my computer to sleep, then when I’d come home my computer would be on. Some would ask what’s the problem with that? Well the problem is that I set no wake-up timers and wake-on-LAN is turned off. So when the power went out while my computer was updating itself because it decided to turn itself back on while I was away…it forced me to do a restore from my Windows Home Server. Thankfully the WHS backup worked great.
So I set out on hunting down the problem and I’ve compiled all the helpful hints and processes I’ve found for tracking down why your computer is turning itself back on.
My problem specifically stemmed from that I have Windows 7’s Media Center installed, setup and with the guide updates turned on.
Some general maintenance should always be done first to avoid getting to far into the problem and realizing your computer just needed an update.
1. Update your computer with Windows Update (Windows Vista and Windows 7 users just go to the Start Menu and type in the search area “Windows Update” without the quotes to get them started).
2. Go to your computer’s website and download the latest BIOS update. Refer to the manufacturer’s instructions and update your BIOS via it.
Next, if you’re still having problems, it’s time to start troubleshooting. You can find which devices are set to be allowed to wake up your computer by running the following command in the command prompt: powercfg –devicequery wake_armed . If you see something in there out of the ordinary, or that makes you palm –> face then you’ve probably found the culprit and can GOTO 10: rejoice AFTER turning off the device’s ability to wake the computer by performing the following: in device manager, right-click the device listed in Step 2 and select Properties, switch to Power Management tab and clear the checkbox of Allow this device to wake the computer.
Now for me, none of these got me to the solution because it was Media Center’s scheduled update task that was causing the problem, not hardware. So if you find yourself sifting through devices that all seem to be ok, then you should continue on like me and check your Event Viewer (a quick shortcut to the Event Viewer is to go to Start –> Run then type eventvwr.msc and hit enter).
Now look through the System log first, and the Application log second as that should be the proper order of probability. If you find that your computer seems to be waking up at say 4:17pm everyday like mine, then look for events around that time, usually right next to the first event at that time, that could be a culprit like a scheduled task.
I found event stating that mcupdate_scheduled had requested to wake the computer. It looked like this:
Event Source: power-troubleshooter
The system has resumed from sleep.
Sleep Time: 2009-11-07T17:01:22.662051300Z
Wake Time: 2009-11-07T22:14:14.102034400Z
Wake Source: Timer – Windows will execute ‘\Microsoft\Windows\Media Center\mcupdate_scheduled’ scheduled task that requested waking the computer.
Since it was listed as a scheduled task in the Event Viewer, then I knew to continue on to the Task Scheduler to remove or change that task’s properties (a quick shortcut to the Task Scheduler is to go to Start –> Run then type taskschd.msc and hit enter). From the Task Scheduler you can either search for the task name, or browse down through the hierarchical menus. The path through the menus is given to you from the item found in the Event Viewer. Thus I navigated down the folders from Microsoft –> Windows –> Media Center and then found the mcupdate_scheduled task. From here you can delete the task or modify it’s properties, like I did, to simply not allow the task to wake the computer to perform the task. Voila!
As always, feel free to comment if you need help with a similar issue!