Scenario: A Windows 7 machine running VMWare Server as a host for a Windows 2008 R2 guest OS.
Problem: Slow performance transferring files to/from the guest OS.
Solution: Performance issues with bridged networking on Windows Server 2003 and Windows 2008 host operating systems. (It worked with Windows 7 too).
I was trying to add a new COM DLL to my VS2010 project but it kept giving me the following error message:
A reference to the “….dll” could not be added.Please make sure that the file is accessible and that it is a valid assembly or COM component
Then I realised I hadn’t registered my self-registering assembly on my machine as this was a new machine and the first time I had used this project. Since I had my VS Command Prompt open I ran RegSvr32 on the assembly and waited for the usual message. Instead it threw me an error and I was left to try and find out what was causing the problem. As it turns out the solution was relatively simple. I needed to run my command prompt as the administrator to get RegSvr32 to work as I am using a Windows 7 OS. Now my COM DLL is registered and listed in the COM tab of the Visual Studio Add Reference dialog.
How do we stop those trigger happy web users who feel the need to press buttons more than once. One way is to disable/change the button on the first click. All that is required is a couple of simple lines of code to make this happen. In my Page_Load event I have the following;
if (!IsPostBack)
{
MyASPNetButton.Attributes.Add("onclick", "this.value='Please wait...'; this.disabled=true;" + Page.ClientScript.GetPostBackEventReference(MyASPNetButton, "").ToString());
}
If your web services are running on a server that is not in the DMZ and you are not able to open port 80 to these services either then you will encounter a common scenario. Your Silverlight application will not be able to connect to these services because it can’t get to the clientaccesspolicy.xml file that is required to access services on a different server to the one that served your Silverlight application.
If you hosting your Silverlight application on a machine running IIS 7.5 (Windows Server 2008) then help is at hand – click here for more details.
This is a bit more of an unusual situation that I found a fix for.
I had set up my Windows 7 x64 machine so that I could connect to it remotely. When I got to work I tried the connection from the Windows XP (SP3) machine that I had been given to use. It was at least running IE8 but when I fired up the connection to the remote machine IE crashed, told me I needed to report the error then recovered enough to let me know it could not connect to my remote machine.
A quick bit of surfing later and the answer appeared in the form of this answer from Microsoft.
Apparently I didn’t have IPV6 installed on the machine, but doing the installation solved the problem.
I am a big fan of Silverlight, its just so much fun to develop with. However, time and tide wait for no man so I am glad MS has updated support for HTML5. I am sure I will get round to learning more about it soon…
I got the following error while trying to upgrade a site feature in SharePoint:
The copying of this file failed: Feature.xml. Access to the path 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Features\<MyFeature>\Feature.xml' is denied.
I hadn’t changed any of the SP settings and the process for doing the deployment hadn’t changed so what was SP getting upset about now??? Taking a look at the directory where the Feature.xml was supposed to be installed provided me with the answer. For some reason, yet to be explained by computer science, the directory was left in a state of limbo. I couldn’t open it to view the content, see the security settings or rename/delete it. First of all I tried resetting IIS to see if that would release its grip on this defunct directory but this gave me no further progress. In the end I restarted the machine, the phantom directory disappeared and I was able to continue on with my deployment process as normal.
Its a well known fact that Using HTTP Compression for Faster Downloads makes good sense. Also, if you have any problems getting this to work then Troubleshooting HTTP Compression in IIS6 is a good place to start.
This is just a little ‘note to self’ about using the IIS Metabase Explorer to configure your web server for compression, specifically at a site level. My situation arose because the IT guys didn’t want to apply compression across every site on the server, if it wasn’t necessary. I was using the Metabase Explorer to change my IIS settings and having configure the HcDoDynamicCompression, HcDoDynamicCompressionLevel and HcScriptFileExtensions records for defalte and gzip keys, I went to set the DoDynamicCompression record for the site.
After creating the DoDynamicCompression record on the root node for the site and changed the value to 1 (true) I went to check the response from the server. To my surprise the response still wasn’t being compressed. After a bit of head scratching I deleted the DoDynamicCompression record and then re-added it, this time using the adsutil IIS admin script. After checking the response and finding it was now compressed successfully I went back to the Metabase Explorer to see what was different.
For site level compression there are a couple of additional values that need setting for the DoDynamicCompression record:
I have been using IIS Express to do some of my recent development instead of using the ASP.NET Development Server so that I could use the additional functionality within IIS. (Personally, I hate developing with the ASP.NET Development server but I am having to develop on XP at the moment and IIS 5.1 is not much better. Getting IIS Express has been a real bonus.). I had configured my IIS site originally with a localhost address and Visual Studio debugging worked fine. Unfortunately, Fiddler doesn’t like monitoring localhost addresses so I created a new entry in my Hosts file to use localhost.
This created my second issue. When I tried to run my app within VS I got the ‘Unable to start debugging on the Web server’ error, IISExpress was reporting 401 errors and all because of the entry in the Hosts file. So after the usual search to try and find similar problems I came across this MSDN KB article. I actually used Method 2 in the article and I didn’t need to reboot my machine, just restart my IISExpress instance. This solved my problem as Visual Studio was then happy to go through the authentication process and Fiddler was capturing my Requests/Responses.
Having done some intensive research over the last couple of days to define exactly what happens when you set your IE browser to Compatibility View I thought it was worth noting a few things down.
These are some of the useful links I have found whilst scouring the web for relevant information:
GP23 Consulting 