Configuring Visual Studio To Work With a Proxy

By default, Visual Studio and Nuget use your proxy settings from IE.  However, I work for a corporation that insists on continually reverting my IE proxy settings every 15 to ones that do not work with Visual Studio, meaning that I need to continually update them just to do my job.  The solution is to configure Visual Studio and Nuget directly to use your proxy so they do not rely on IE.

This post outlines how to configure the many components of VS to work with a proxy, however for Nuget it instructs to use the nuget.exe, which requires finding it.  An easier way is to edit the Nuget configuration file directly.  Also for most people you don't need to specify your credentials as the proxy is usually configured to use integrated authentication by default.  Below is a summarised version of the steps required to get VS and Nuget to work:

• Open the VS configuration file located at "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe.config".  Change the path appropriately depending on your version of Visual Studio and whether you are using the x64 or x86 variant.
• Update the configuration section to look as follows:

<system.net>

<settings>

<ipv6 enabled="true"/>

</settings>

<defaultProxy useDefaultCredentials="true" enabled="true">

<proxy bypassonlocal="true" proxyaddress="http://address:port" />

</defaultProxy>

</system.net>

• Open the Nuget configuration file located at "%AppData%\NuGet\NuGet.Config"
• Update the configuration section to look as follows:

<configuration>

...

<config>

<add key="http_proxy" value="http://address:port" />

</config>

...

</configuration>

• Restart (or start) Visual Studio and confirm that you can restore and browse for packages successfully

Thanks to the this answer on SO for the location of the Nuget config file

adb sideload Nexus Android - "Device not found" correct fix

The issue is that you follow the instructions to sideload a factory Android image to your Nexus and when you put the phone in adb sideload mode and try to upload the image, you receive the message "device not found".  This may happen even though you previously could see that the device was connected to your computer and listed using adb devices.  Other people have posted how to fix the issue but it does not work for you or you.

The page linked above talks about modifying the driver inf file to include the identifier of your specific Nexus device.  The problem with this, is that it appears the USB driver is no longer update by Google for specific Android devices (even if you grab the latest using the SDK manager) nor does it actually need to be if you follow these instructions.  Actually, updating the inf file means that Windows will be able to automatically detect and install drivers for your device, but it can be difficult for the average user to find the device identifier and do this.  Instead it is easier to do the process manually:

1. Follow the instructions above until you get your device to the point where you have selected sideload using adb from the recovery screen and your device is displaying Now send the package you want to apply to the device with "adb sideload "
2. At this point you may see Windows pop up a dialog with the text Installing drivers for your device but it will fail and be unable to find the drivers.  Usually at this point, you will be unable see the device in your device manager and manually install the drivers
3. Unplug your device and plug it back in.  Again you should Windows attempt to install drivers for your device.  This time when it fails, go to the device manager and you will see Android device with an exclamation mark.  You can now manually install a driver for the device by using the Google USB drivers you downloaded.  You will be presented with 3 options - select ADB composite device and the drivers will be installed
4. You can now sideload the device using the command adb sideload  as described above

If you need to find the USB driver manually because you do not have the SDK manager, you can find more details here.

Restoring A Windows 7 Backup To A New Hard Drive

A common scenario is to use the built-in Windows 7 Backup & Restore functionality to create a system image, then install a bigger hard drive and try to restore the image to the new hard drive.  When i tried to do this, i got the error:

No disk that can be used for recovering the system disk can be found

A quick search showed me i was not alone - even if the destination drive was the same size or bigger, i still got the error.  Finally i found the following solution:

1. Boot into the Windows 7 DVD
2. Format the destination drive to a single, empty partition (you can do this through the Windows 7 installer 'Advanced options' dialog)
3. Select 'repair my computer'
4. Open the command prompt
5. Type diskpart to start the disk partition tool
6. Type select disk=0 to change to the destination drive
7. Type detail disk to check the details of the drive and ensure it is the correct one.  If not, repeat steps 6 & 7 with a different index until the correct disk details are displayed
8. Type clean to reset the disk
9. Type exit to exit the diskpart tool
10. Select Restore from a system image and follow the wizard

The restore process should now complete successfully.  I found the above steps from the accepted answer in this thread.

Pairing The Logitech m555b Bluetooth Mouse With Windows 7 x64

If you are unable to pair your bluetooth mouse (in my case the Logitech m555b) with Windows 7, try the following.  In my case, Windows could see the mouse but sat there spinning its wheels while trying to connect.  To get it to work, when it discovered the mouse and displayed it in the 'add device' dialog, i right-clicked the mouse, ticked 'Drivers for keyboard, mice, etc' which forced the HID drivers to be installed and the mouse started to work fine.  I then cancelled the 'add device' dialog as it continued to search for other devices. Let me know in the comments if it fixes your issue!  The below screenshot was taken from this thread.

Running Windows 7 in a Virtual Machine Under OSX To Double Battery Life

I have had a Macbook Pro for a few years now and absolutely love the hardware (currently have an i7 model) but personally even after all this time find the usability of OSX far inferior.  I don’t want this post to turn into a debate about which is better, but if you prefer Windows 7 to OSX then you may find some value in this post.

Up until recently I have been running Windows 7 natively (ie – using Bootcamp drivers) on the Mac and it runs flawlessly, except for one issue which has always griped me – battery life.  The problem is that Apple do not provide a driver for their graphics switching magic voodoo hardware solution, so under Windows 7, the dedicated NVidia or ATI graphics chip is constantly used.  This is fine if you use the Mac to play games all day long, but if like me you are just doing development or word processing, etc it is a pain that your 7-8+ hours of battery life under OSX is reduced to 3-3.5 hours under Windows 7.  Not to mention the MBP gets much hotter due to the graphics chip working overtime.  So after realising there is no native solution (and probably will not be in the foreseeable future, if ever) I came to the conclusion that the only hope was to run Windows 7 in a VM under OSX and then force the graphics in the MBP to always use the integrated graphics using the excellent gfxCardStatus utility.  This utility allows you to force OSX to use either the integrated graphics, dedicated graphics or auto switching feature of the operating system which is cool.  Personally I set it to always use integrated graphics which I have found fine for every application I have tried, even GPU intensive ones, but the choice is always there to use switching if required which is nice.

As a VM solution I am currently trialing Parallels, which most objective reviews that I have read (ie – ignoring forums full of people stating their ‘preferences’) is superior in performance.  The result I have observed are as follows:

Windows 7 native (Bootcamp)	3 – 3.5 hours
Windows 7 running under Parallels	5.5 – 7 hours

The variation I have experienced is due to what applications you use during a given session.  Unfortunately I do not have much time so I cannot present more comprehensive results, but the above was gathered over 10 days.  So clearly, when it is able to use the integrated graphics, Windows is able to achieve very close to what I get under OSX.  If only Apple would release a native driver … Still I don’t hold my breath so I highly advise this solution to all Windows 7 users.  You also get a few other improvements as an added bonus.  First of all, the ACPI capabilities now function correctly (again lack of drivers from Apple is a cause of this) so that the screen reacts promptly and quickly to ambient light changes.  You also get the ability to switch to OSX which is handy if you are doing iOS dev, etc and the ability to seamlessly integrated with OSX applications is nice (ie open files with OSX applications).

There are some downsides of course.  Performance is not as good as running natively – whilst many people in the Apple forums seem ‘happy’ with the performance (always a great word to use when measuring performance) it is clearly slower than running Windows natively.  The problems largely come when you switch between Windows and OSX.  If you stay in either it is fine, but it is not uncommon for me to wait minutes after switching from Windows to OSX before OSX even becomes responsive.  Applications take noticeably longer to load in a VM and so on.  WPF applications do not perform correctly under Parallels unless you turn off graphics acceleration.  However most of these issue come to IO limitations.  You can clearly hear the hard drive being thrashed to bits and would be largely solved with the use of an SSD.

I am out of time so in conclusion, all I can say is give it a go for yourself, but given the doubled battery life I achieve when running in a VM, I am happy to put up with the relatively small losses I observe.  As for the actual VM software, I think largely all three options (Fusion, Parallels and VirtualBox) are going to be comparable in performance.