Parallels 11 or VmWare Fusion 8.x Windows VM is running too slow on Retina MacBook Pro


I’ve been having this problem on my MacBook Pro 2015 Retina edition when running Windows 10 in Parallels 11 or VmWare Fusion 8.x

The machine is just so slow, it is almost intolerable.

After checking what was going on I discovered that the display service was consuming too much CPU.

The fix? Disable Retina support and use scaling instead.  I guess it is just far too many pixels for the VM Host to handle.

Yes, unfortunately the display quality will suffer greatly, but it is not unusable, and the performance boost you get is well worth it.

This works for both VmWare Fusion and Parallels Desktop.

I hope that eventually both companies will solve this.

Advertisements

Update-Database fails in Package Manager Console on Windows 10 Insider Preview with ambiguous type error


This post is about providing a workaround for this problem until Microsoft provide us with a proper fix.

This problem has been reported here:

There seem to be two types that fail due to ambiguity:

  • Microsoft.VisualStudio.Shell.Package
  • NuGet.VisualStudio.IVsPackageInstallerServices

Yet if you have other failing types in your scenario, understand this post and apply the same logic to your specific case.

Microsoft.VisualStudio.Shell.Package

This workaround fixes the following error:

Type name 'Microsoft.VisualStudio.Shell.Package' is ambiguous, it could be 'Microsoft.VisualStudio.Shell.Package, Microsoft.VisualStudio.Shell.14.0, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or 'Microsoft.VisualStudio.Shell.Package, 
Microsoft.VisualStudio.Shell.10.0, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

To fix this, do the following:

  1. Open Windows PowerShell ISE in admin mode (right click and Run as Administrator)
  2. Open the following file:
    • C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 14.0\COMMON7\IDE\EXTENSIONS\ZPM4HZQB.YOS\Modules\NuGet\Profile.ps1
  3. Go to line number 126 (Ctrl+G and enter the number)
  4. Find this line:
    • $service = [Microsoft.VisualStudio.Shell.Package]::GetGlobalService($ServiceType)
  5. Replace it with these lines:
    • $accel = [psobject].Assembly.GetType("System.Management.Automation.TypeAccelerators")
       $accel::add(“specificShell”,”Microsoft.VisualStudio.Shell.Package, Microsoft.VisualStudio.Shell.14.0, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”)
       $service = [specificShell]::GetGlobalService($ServiceType)
  6. If your Visual Studio is open, you will need to close it and re-open it, as it caches a copy of this script.

NuGet.VisualStudio.IVsPackageInstallerServices

This is a similar fix to the above, but for this error:

Type name 'NuGet.VisualStudio.IVsPackageInstallerServices' is ambiguous, it could be 'NuGet.VisualStudio.IVsPackageInstallerServices, JetBrains.Platform.VisualStudio.SinceVs11, Version=104.0.0.0, Culture=neutral, PublicKeyToken=1010a0d8d6380325' or 
'NuGet.VisualStudio.IVsPackageInstallerServices, JetBrains.PsiFeatures.VisualStudio.SinceVs11, Version=104.0.0.0, Culture=neutral, PublicKeyToken=1010a0d8d6380325'.

To fix this, do the following:

  1. Open Windows PowerShell ISE in admin mode (right click and Run as Administrator)
  2. Open the following file (replace {NuGetPackagesFolder} with the location of your packages folder in your solution:
    • {NuGetPackagesFolder}\EntityFramework.6.1.3\tools\EntityFramework.psm1
  3. Go to line number 1004 (Ctrl+G and enter the number)
  4. Find this line:
    • $packageInstallerServices = $componentModel.GetService([NuGet.VisualStudio.IVsPackageInstallerServices])
  5. Replace it with these lines:
    • $accel = [psobject].Assembly.GetType("System.Management.Automation.TypeAccelerators")
       $accel::add(“NuGetInstallerServices”,”NuGet.VisualStudio.IVsPackageInstallerServices, JetBrains.Platform.VisualStudio.SinceVs11, Version=104.0.0.0, Culture=neutral, PublicKeyToken=1010a0d8d6380325”)
       $packageInstallerServices = $componentModel.GetService([NuGetInstallerServices])
  6. As above, if your Visual Studio is open, you will need to close it and re-open it, as it caches a copy of this script.

The Logic

All I am doing here is quite simple, I am creating a type alias that points to a specific assembly instance, and using that for reference, rather than the version that would resolve into multiple instances.

A Few Notes

The workaround above, particularly the second one, is temporary, and will fail again if you refresh your NuGet package cache before MS come up with a fix for this problem.

Also, since all machines have different configurations, your specific assemblies might be different.  So just replace them above accordingly… you are all devs after all ;)

Of course, to fix, simply re-apply the patch above.

This problem is still present as of Windows 10 Insider Preview Build 14257.rs1_release.160131-1800

Delay email sending in Outlook (like gmail)


Today I decided to change one annoyance about Outlook… the fact that it sends out emails immediately and there’s no way to ‘undo’.

I have tried alternatives, like ‘explicit sending’, which results in my forgetting that the email didn’t go out, or using ‘delayed sending’, which is a pain, since you need to do it every time.

Wouldn’t it be better if I could have the option to ‘undo’ sending an email, or just let it be otherwise?

So, I’ve written this quick script in VBA which does just that.  In my case, it delays the sending of the email by 5 minutes… if you don’t withdraw it within that time, it simply gets sent… you can change the value to your liking in the code.

To get this done, simply add the following code to your ‘ThisOutlookSession’ class.


Private Sub Application_ItemSend(ByVal Item As Object, Cancel As Boolean)
 Const defaultDelayInMinutes As Integer = 5

Dim timeToSend As Date
 Dim mi As Outlook.MailItem

 On Error GoTo ErrorHandler

 timeToSend = Now + TimeSerial(0, defaultDelayInMinutes, 0)

 Set mi = Item
 mi.DeferredDeliveryTime = timeToSend
Exit Sub

ErrorHandler:
 MsgBox "Application_ItemSend: " & Err.Description
End Sub

Very handy tip for anyone doing ASP.NET MVC using AsyncController and experiencing timeouts

C# Disciples

Today I stumbled upon a timeout issue while building a web application and felt like I need to share this for those that like me wasted/are wasting hours trying to figure out why you are getting a timeout.

Here is a diagram that show the structure of the request response stack I have.

image

The reason why I went for an AsyncController is that the long running operation is not CPU-bound processing thus the thread that would be waiting for the response would be wasting its time waiting. More info on why and how to use Async Controllers in MVC3 can be found here.

All is fine and good until my I hit a request that took more than 1 minute, and then the nightmare of timeouts begun… So first thing I did is make sure I make the timeout for the WCF service longer. You can do this by…

View original post 150 more words