I know this is not a technical blog – but I found it is encouraging to keep a collection of my favorite quotes and update it whenever I found a good one.
Today’s quote come from my build team:
“A true hero need not speak. The world will speak for him when he is gone”
Ping back from : http://blogs.telerik.com/kevinbabcock/posts/08-12-23/visual_studio_ldquo_error_creating_control_rdquo.aspx
I’ve run into this error before and last night it reared its ugly head again. You’ll find it from time to time when switching to Design View in Visual Studio to work with custom server controls. The bug is in Service Pack 1 of VS and can be quite annoying.
It has been submitted to Microsoft and they claim to be working on a solution which will “fix it in subsequent releases” of Visual Studio. Unfortunately, developers (like me) don’t want their productivity to suffer while we all wait for a fix from Microsoft. So here are a couple of steps you can take to try to resolve this issue yourself:
Solution 1. Close and restart Visual Studio. Some developers claim this solved the problem for them. I cannot confirm that this works because it did not solve the problem for me, but it’s certainly worth a try since it’s quick and does not require you to modify your system in any way.
Solution 2. Delete all project assemblies from your ProjectAssemblies directory.
The second solution did the trick for me. Hopefully one of the above solutions worked for you. If you have run into this bug and found an alternate solution, please let me know and I’ll make sure it gets added to the list.
At a client we were testing our newest line of development machines. After installing Visual Studio 2010 we noticed that the performance was VERY slow when connecting to Team Foundation Server (2010). Performing a get latest of a large solution took several hours(!).
Some investigation showed that it does not appear to be a TFS issue per se but rather something lower in the .NET Framework stack, having to do with automatic proxy discovery through the WPAD protocol.
You can work around the issue by turning off proxy autodiscovery on a per-application basis by using a .exe.config setting.
The .exe.config for Visual Studio is %VSINSTALLDIR%\Common7\IDE\devenv.exe.config and it already contains a section in the .exe.config for System.Net. After adding the defaultProxy element, that section would look like this:
1: <system.net>
2: <defaultProxy enabled="false" />
3: <settings>
4: <ipv6 enabled="true"/>
5: </settings>
6: </system.net>
Have you ever feel envious with Mac OS user because of the way Mac OS renders font ?OK, I admitted I did. But no more – with the help of these things:
Installation:
- Download these 2 files above.
- Extract the GDI++ into your Program menu folder, then put a shortcut of Gditray.exe into Startup folder
- Extract and copy the 2 Lucida Grande fonts into C:\Windows\Fonts
- Execute the .reg file
Usage:
After that, you will see GDI++ icon in the task bar. Click Use preferences –> Bold / Medium / Light.
Click Enable
Results:
This is what looks like with GDI enabled:
And GDI disabled:
If you want to use Visual Studio 2008 SP1 and Team Explorer 2008 to connect to a TFS 2010 server, you will probably hit the error while trying to add the server. It happen even when you install patch KB974558 (Team Explorer 2008 SP1 forward compatibility patch for TFS 2010)
The Team Explorer 2008 RTM build is 9.0.21022.8. If you install Visual Studio 2008 SP1 before installing Team Explorer, then you’ll have VS 2008 SP1 with Team Explorer RTM which does not work well together.
Figure 1 : this Team Explorer build does not work well with Visual Studio 2008 SP1 and TFS 2010
So the fast solution is to run the Visual Studio 2008 SP1 again. It will look for the Team Explorer version and update to SP1. After installation complete, we should see this:
Figure 2: Now the Team Explorer is patched to SP1 build : 9.0.30729.1, this version works with TFS 2010.
