Thursday, February 7. 2013
Skype Collaboration Provider Not Listed
On a project at a new client we are using the Skype Collaboration Provider for VS2010. For some unknown reason, after running the apropriate installer, the Skype Collaboration Provider did not show in the dialog where you can choose the desired provider.
Repairing, uninstalling, rebooting and re-installing the the provider multiple times, did not end up in the desired result. I still could not select the Skype Collaboration Provider from the Personal Settings dialog. As if it just was NOT installed at all. Finally I had an epiphany... Maybe it just did not install to the correct location! So I investigated the location of the Windows Live Messenger Collaboration Provider. To my surprise the Skype provider was not in the same directory! Eureka!
It seems that the Skype Collaboration Provider installer puts the binaries in the default installation directory of VS2010. And as I did not install my VS2010 in the default location, the binaries could not be found. The final solution was quite simple. Just copy the binaries to the correct location... Sigh
- Yes, VS2010 Service Pack 1 is installed correctly.
- Yes, Team Foundation Power Tools for VS2010 are installed correctly.
Repairing, uninstalling, rebooting and re-installing the the provider multiple times, did not end up in the desired result. I still could not select the Skype Collaboration Provider from the Personal Settings dialog. As if it just was NOT installed at all. Finally I had an epiphany... Maybe it just did not install to the correct location! So I investigated the location of the Windows Live Messenger Collaboration Provider. To my surprise the Skype provider was not in the same directory! Eureka!
It seems that the Skype Collaboration Provider installer puts the binaries in the default installation directory of VS2010. And as I did not install my VS2010 in the default location, the binaries could not be found. The final solution was quite simple. Just copy the binaries to the correct location... Sigh
Wednesday, June 1. 2011
MSBuild Exec task - IgnoreStandardErrorWarningFormat
If you are using MSBuild 4.0.30319 and try to set the property IgnoreStandardErrorWarningFormat on the Exec task you might run into the following message error:
The solution is very, very simple: be sure to add ToolsVersion="4.0" to the Project tag.
<Project DefaultTargets="Bla" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<Target Name="Bla">
<Exec IgnoreStandardErrorWarningFormat="true" Command="dir /w" />
</Target>
</Project>
error MSB4064: The "IgnoreStandardErrorWarningFormat" parameter is not supported by the "Exec" task.
The solution is very, very simple: be sure to add ToolsVersion="4.0" to the Project tag.
<Project DefaultTargets="Bla" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<Target Name="Bla">
<Exec IgnoreStandardErrorWarningFormat="true" Command="dir /w" />
</Target>
</Project>
Monday, May 9. 2011
Upgrade test project from VS2005 to VS2010
The solution contains several projects, including test projects. All of which now target .Net Framework 2.0 (although some already reference .Net Framework 3.0 or 3.5 assemblies). We do not want to upgrade to .Net Framework 4.0 just yet. Goal of the upgrade is to have every project in the solution target .Net Framework 3.5.
After converting the solution to VS2010 most of the projects reference .Net Framework 2.0. Some of which do not build, because of references to assemblies targeted at a higher .Net Framework. Visual Studio 2010 does not allow cross-referencing to higher .Net Framework assemblies. Fixing this problem is quite simple: just re-target the project to .Net Framework 3.5.
All of the test projects have been set to .Net Framework 4.0. One could discuss if this is acceptable for test projects as these will not be released. But for now it was decided to keep every project targeted at .Net Framework 3.5. Fortunately most of the test projects were easily re-targeted to .Net Framework 3.5. Hint: if you run into problems here, make sure VS2010 SP1Rel is installed.
For one of the test projects the solution just would not load it if re-targeted at .Net Framework 3.5. Each time the project was re-targeted, the conversion wizard would just pop up and set it back to .Net Framework 4.0. Eventually we found a workaround by editing the project file by hand after the conversion.
Two manual fixes were needed:
After converting the solution to VS2010 most of the projects reference .Net Framework 2.0. Some of which do not build, because of references to assemblies targeted at a higher .Net Framework. Visual Studio 2010 does not allow cross-referencing to higher .Net Framework assemblies. Fixing this problem is quite simple: just re-target the project to .Net Framework 3.5.
All of the test projects have been set to .Net Framework 4.0. One could discuss if this is acceptable for test projects as these will not be released. But for now it was decided to keep every project targeted at .Net Framework 3.5. Fortunately most of the test projects were easily re-targeted to .Net Framework 3.5. Hint: if you run into problems here, make sure VS2010 SP1Rel is installed.
For one of the test projects the solution just would not load it if re-targeted at .Net Framework 3.5. Each time the project was re-targeted, the conversion wizard would just pop up and set it back to .Net Framework 4.0. Eventually we found a workaround by editing the project file by hand after the conversion.
Two manual fixes were needed:
- Change reference of "Microsoft.QualityTools.UnitTestFramework" to
<Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" /> - Remove contents of the tag
<FileUpgradeFlags>0</FileUpgradeFlags>, which hints VS2010 to start the conversion wizard.
« previous page
(Page 1 of 2, totaling 6 entries)
next page »
