I opened our solution in Visual Studio 2017 but some testing references aren't found, specifically:
Microsoft.VisualStudio.QualityTools.CodedUITestFramework
Microsoft.VisualStudio.TestTools.UITest.Common
Microsoft.VisualStudio.TestTools.UITesting
Opening under VS2015 they load fine and I can see the references under the Visual Studio 2015 folder structure "Microsoft Visual Studio 14.0\Common7\IDE\PublicAssemblies\".
However they don't appear under the 2017 installed files: "\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\".
How can I get VS to pick up these references, am I missing a plug-in or extension? Have they been consolidated or deprecated?
Microsoft Visual Studio Enterprise 2017
Version 15.0.26228.4 D15RTWSVC
Microsoft .NET Framework
Version 4.6.01055
If you are running VS 2017 Enterprise then you can use this solution to add Coded UI Test back.
https://stackoverflow.com/a/42788766/2563765
If you want to remove those references in your project because you are not using Coded UI Test anymore, you can
1) Unload your project
2) Edit the .csproj file
3) Find
<IsCodedUITest>True</IsCodedUITest>
<TestProjectType>CodedUITest</TestProjectType>
and repleace with
<IsCodedUITest>False</IsCodedUITest>
<TestProjectType>UnitTest</TestProjectType>
4) Remove
<Choose>
<When Condition="'$(VisualStudioVersion)' == '10.0' Or '$(VisualStudioVersion)' == '11.0'">
<ItemGroup>
<Reference Include="UIAutomationTypes" />
</ItemGroup>
</When>
</Choose>
and
<Choose>
<When Condition="'$(VisualStudioVersion)' == '10.0' And '$(IsCodedUITest)' == 'True'">
<ItemGroup>
<Reference Include="Microsoft.VisualStudio.QualityTools.CodedUITestFramework, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<Private>False</Private>
</Reference>
<Reference Include="Microsoft.VisualStudio.TestTools.UITest.Common, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<Private>False</Private>
</Reference>
<Reference Include="Microsoft.VisualStudio.TestTools.UITest.Extension, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<Private>False</Private>
</Reference>
<Reference Include="Microsoft.VisualStudio.TestTools.UITesting, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<Private>False</Private>
</Reference>
</ItemGroup>
</When>
</Choose>
if found
5) Reload the project
Related
I'm trying to create a custom checkin policy in TFS 2013. Followed this example and I create WorkitemStateControlPolicy class below
https://blog.devart.com/creating-tfs-custom-check-in-policy.html
namespace WIStateControlPolicy
{
[Serializable]
public sealed class WorkitemStateControlPolicy : PolicyBase
{
[NonSerialized]
private IPendingCheckin pendingCheckin;
public const string ClosedStatus = "System.Reason";
........
........
}
}
I build this project, WorkitemStateControl.dll created. Registy key I am using:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\14.0_Config\TeamFoundation\SourceControl\Checkin Policies]
"WorkitemStateControl"="c:\\Users\\me\\Desktop\\dll\\WorkitemStateControl.dll"
Then I checked the visual studio 2015 add checkin policy but new policy is not visible in list
I tried also this registy path:
(HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\11.0\TeamFoundation\SourceControl\CheckinPolicies)
But problem not changed.
My queston is, why new checkin policy is not visible? Should I change anything on tfs server?
There is not really a concept of a Check-in policy to go hand-hand with a version of Team Foundation Server. Instead these are plugins for Visual Studio. So you'rn buiding a plugin for that specific version of Visual Studio that happens to connect to a Team Foundation Server.
A such, each version of Visual Studio needs its own versions of the assemblies, compiled against the correct version of .NET and the correct version of the Team Foundation Server Client Object Model that matches the version that ships with the Team Explorer "extension" for Visual Studio.
You then register a different path to the specific assembly containing the policy into each registry tree of the version of Visual Studio you support. Ohh and don't forget to register the x86 and the x64 registry trees :).
Windows Registry Editor Version 5.00
//v12
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Checkin Policies]
"JesseHouwing.CheckinPolicies"="C:\Program Files(x86)\\MyCompany\\Checkin Policies\\v12.0\\JesseHouwing.CheckinPolicies.dll"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Checkin Policies]
"JesseHouwing.CheckinPolicies"="C:\Program Files(x86)\\MyCompany\\Checkin Policies\\v12.0\\JesseHouwing.CheckinPolicies.dll"
//v14
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\TeamFoundation\SourceControl\Checkin Policies]
"JesseHouwing.CheckinPolicies"="C:\Program Files(x86)\\MyCompany\\Checkin Policies\\v14.0\\JesseHouwing.CheckinPolicies.dll"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\14.0\TeamFoundation\SourceControl\Checkin Policies]
"JesseHouwing.CheckinPolicies"="C:\Program Files(x86)\\MyCompany\\Checkin Policies\\v14.0\\JesseHouwing.CheckinPolicies.dll"
etc...
All the details are in this blog post.
VISUAL STUDIO PROJECT TYPE CPU .NET VERSION TFS OM VERSION VISUAL STUDIO VERSION
2017 Class Library AnyCPU 4.6 15.0.0.0 v15.0
2015 Class Library AnyCPU 4.6 14.0.0.0 v14.0
2013 Class Library AnyCPU 4.5 12.0.0.0 v12.0
2012 Class Library AnyCPU 4.0 11.0.0.0 v11.0
2010 Class Library AnyCPU 4.0 10.0.0.0 v10.0
2008 Class Library AnyCPU 3.0 9.0.0.0 v9.0
2005 Class Library AnyCPU 2.0 8.0.0.0 v8.0
And a sample project that targets multiple Visual Studio Versions.
In this project I've manually tweaked the project files to dynamically reference the version of the Client Object Model depending on the selected Visual Studio version using a choose/when construct:
<Choose>
<When Condition="'$(Configuration)' == 'VS2013'">
<ItemGroup>
<Reference Include="Microsoft.TeamFoundation.VersionControl.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
<Reference Include="Microsoft.TeamFoundation.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
<Reference Include="Microsoft.TeamFoundation, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
</ItemGroup>
</When>
<When Condition="'$(Configuration)' == 'VS2012'">
<ItemGroup>
<Reference Include="Microsoft.TeamFoundation.VersionControl.Client, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
<Reference Include="Microsoft.TeamFoundation.Client, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
<Reference Include="Microsoft.TeamFoundation, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
</ItemGroup>
</When>
<When Condition="'$(Configuration)' == 'VS2010'">
<ItemGroup>
<Reference Include="Microsoft.TeamFoundation.VersionControl.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
<Reference Include="Microsoft.TeamFoundation.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
<Reference Include="Microsoft.TeamFoundation, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
</ItemGroup>
</When>
<Otherwise>
<ItemGroup>
<Reference Include="Microsoft.TeamFoundation.VersionControl.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
<Reference Include="Microsoft.TeamFoundation.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
<Reference Include="Microsoft.TeamFoundation, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
</ItemGroup>
</Otherwise>
</Choose>
You can use similar tricks to reference different NuGet versions for later versions of Team Explorer. The TFS Aggregator project is built against every version of the Client Object Model since 2013 and we dynamically include a targets file to setup the references and nuget dependencies.
Starting from today, a WPF project that belongs to a solution with 20 projects, set all my references to missing
I've just checked the MS suggestion and the other answers on Stackoverflow but none worked...I've tried to re-get solution from SVN, with no luck, other colleagues haven't got this problem.
I've also tried to remove and re-add the references (System.Xml for example) .
But no way to make it work...
Any suggestion?
Thanks
UPDATE #1
Here's the csproj
<ItemGroup>
<Reference Include="Catel.Core, Version=4.2.0.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\packages\Catel.Core.4.2.0\lib\net40\Catel.Core.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Catel.Extensions.Controls, Version=4.2.0.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\packages\Catel.Extensions.Controls.4.2.0\lib\net40\Catel.Extensions.Controls.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Catel.Extensions.FluentValidation, Version=4.2.0.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\packages\Catel.Extensions.FluentValidation.4.2.0\lib\net40\Catel.Extensions.FluentValidation.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Catel.Fody.Attributes, Version=2.8.0.0, Culture=neutral, PublicKeyToken=1c8163524cbe02e6, processorArchitecture=MSIL">
<HintPath>..\packages\Catel.Fody.2.8.0\lib\portable-net4+sl4+wp7+win8+wpa81+MonoAndroid14+MonoTouch40\Catel.Fody.Attributes.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Catel.MVVM, Version=4.2.0.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\packages\Catel.MVVM.4.2.0\lib\net40\Catel.MVVM.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="MethodTimer, Version=1.15.7.0, Culture=neutral, PublicKeyToken=cb1364609f40a1dc, processorArchitecture=MSIL">
<HintPath>..\packages\MethodTimer.Fody.1.15.7.0\Lib\portable-net4+sl5+wp8+win8+wpa81+MonoAndroid16+MonoTouch40\MethodTimer.dll</HintPath>
<Private>False</Private>
</Reference>
<Reference Include="Microsoft.Threading.Tasks, Version=1.0.12.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\Microsoft.Bcl.Async.1.0.168\lib\net40\Microsoft.Threading.Tasks.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Microsoft.Threading.Tasks.Extensions, Version=1.0.12.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\Microsoft.Bcl.Async.1.0.168\lib\net40\Microsoft.Threading.Tasks.Extensions.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Microsoft.Threading.Tasks.Extensions.Desktop, Version=1.0.168.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\Microsoft.Bcl.Async.1.0.168\lib\net40\Microsoft.Threading.Tasks.Extensions.Desktop.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="PresentationCore" />
<Reference Include="PresentationFramework" />
<Reference Include="ServiceStack">
<HintPath>..\packages\ServiceStack.4.0.46\lib\net40\ServiceStack.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="ServiceStack.Client, Version=4.0.46.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\packages\ServiceStack.Client.4.0.46\lib\net40\ServiceStack.Client.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="ServiceStack.Common">
<HintPath>..\packages\ServiceStack.Common.4.0.46\lib\net40\ServiceStack.Common.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="ServiceStack.Interfaces, Version=4.0.0.0, Culture=neutral, PublicKeyToken=e06fbc6124f57c43, processorArchitecture=MSIL">
<HintPath>..\packages\ServiceStack.Interfaces.4.0.46\lib\portable-wp80+sl5+net40+win8+monotouch+monoandroid+xamarin.ios10\ServiceStack.Interfaces.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="ServiceStack.Text, Version=4.0.46.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\packages\ServiceStack.Text.4.0.46\lib\net40\ServiceStack.Text.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="System" />
<Reference Include="System.ComponentModel.DataAnnotations" />
<Reference Include="System.Configuration" />
<Reference Include="System.Core" />
<Reference Include="System.IO, Version=2.6.10.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\Microsoft.Bcl.1.1.10\lib\net40\System.IO.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="System.Management" />
<Reference Include="System.Net" />
<Reference Include="System.Runtime, Version=2.6.10.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\Microsoft.Bcl.1.1.10\lib\net40\System.Runtime.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="System.Threading.Tasks, Version=2.6.10.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\Microsoft.Bcl.1.1.10\lib\net40\System.Threading.Tasks.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="System.Windows.Interactivity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\packages\Catel.MVVM.4.2.0\lib\net40\System.Windows.Interactivity.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="System.Xaml" />
<Reference Include="System.Xml.Linq" />
<Reference Include="System.Data.DataSetExtensions" />
<Reference Include="Microsoft.CSharp" />
<Reference Include="System.Data" />
<Reference Include="System.Net.Http" />
<Reference Include="System.Xml" />
<Reference Include="Telerik.Windows.Controls, Version=2015.2.728.40, Culture=neutral, PublicKeyToken=5803cfa389c90ce7, processorArchitecture=MSIL">
<HintPath>..\packages\Telerik.Windows.Controls.for.Wpf.40.Xaml.2015.2.728\lib\net40\Telerik.Windows.Controls.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Telerik.Windows.Controls.GridView, Version=2015.2.728.40, Culture=neutral, PublicKeyToken=5803cfa389c90ce7, processorArchitecture=MSIL">
<HintPath>..\packages\Telerik.Windows.Controls.GridView.for.Wpf.40.Xaml.2015.2.728\lib\net40\Telerik.Windows.Controls.GridView.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Telerik.Windows.Controls.Input, Version=2015.2.728.40, Culture=neutral, PublicKeyToken=5803cfa389c90ce7, processorArchitecture=MSIL">
<HintPath>..\packages\Telerik.Windows.Controls.Input.for.Wpf.40.Xaml.2015.2.728\lib\net40\Telerik.Windows.Controls.Input.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Telerik.Windows.Controls.Navigation, Version=2015.2.728.40, Culture=neutral, PublicKeyToken=5803cfa389c90ce7, processorArchitecture=MSIL">
<HintPath>..\packages\Telerik.Windows.Controls.Navigation.for.Wpf.40.Xaml.2015.2.728\lib\net40\Telerik.Windows.Controls.Navigation.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Telerik.Windows.Data, Version=2015.2.728.40, Culture=neutral, PublicKeyToken=5803cfa389c90ce7, processorArchitecture=MSIL">
<HintPath>..\packages\Telerik.Windows.Data.for.Wpf.40.Xaml.2015.2.728\lib\net40\Telerik.Windows.Data.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="UIAutomationProvider" />
<Reference Include="UIAutomationTypes" />
<Reference Include="WindowsBase" />
Yes I use Nuget, the other 19 points to the same assemblies ...nothing has been moved
UPDATE #2
Since I was not able to proceed I've copied the project from a colleague and now it works.... think something went wrong in the filesystem...have compared the solution and they were identical
The resolution to this issue is.
Whenever you import a project to VS 2015 it modifies your .csproj. So, in order to fix it. Right click on .csproj and open it in notepad or any editor and delete the following
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
Then build your solution and it should work.
In the root directory of the solution, delete everything inside of /packages/ folder, then do a re-build.
It can help to force rebuild the nuget packages. Go to the nuget console and use the following commands: (TOOLS > Options > Package Manager > Package Manager Conbsole)
Update-Package -reinstall -ProjectName "MyProject" -safe
The safe parameter will actually not update the packages, but only reinstall them. If that didn't help, you can try to actually update them (but make sure you have a copy of the project somewhere, just in case.)
Update-Package -reinstall -ProjectName "MyProject"
To force update just one package, use:
Update-Package -id Microsoft.Package.Name -ProjectName "MyProject"
I had this once, caused by a broken .targets import. Check if you accidentally enabled nuget package restore (which includes a .targets file) and then deleted the .nuget directory.
I had similar issue. The solution, which worked for me was to pop the nuget package manager for the solution and refresh the packages.
Another case involved missing packages and nuget package manager for the solution showed updates and dependencies, which needed to be installed and this was the fix.
Another case was exactly as pointed above - delete packages folder fixed it.
Editing manually the project is an option, but there is a chance if you poke where you are not supposed to, your project may not open. If you can, avoid doing that is my opinion.
I've just experienced exactly this in VS2015 on a solution with around 20 projects. Only one project was affected and it lost all references including to the standard .NET assemblies.
The only way I could resolve was to switch to a different GIT branch and then back, this cleaned up the issue and it is all now working.
I also experienced exactly this in VS2015 on a solution with around 10 projects. Only one project - the main MVC project - was affected and it lost all references including to the standard .NET assemblies.
The problem was in my web.config. I had commented some lines, resulting in an invalid xml-file.
This error may occur if you miss .targets file in nuget packages folder. In my case it was
packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.targets
Usually it happens when I'm adding packages to git repository (common .gitignore file is ignoring build folder everywhere) and checkout on another computer.
Tip: you can modify .gitignore file to include all files in packages folder. Append these lines to the bottom:
# Include all files in NuGet packages directory
!/packages/**/
For me I had mistakenly removed the following line from .csproj file:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
So I closed Visual Studio. Opened myprojectname.csproj file and added the line.
then I reopened the solution and by that I was able to resolve my issue.
Unload project, then edit project
look for the following and delete.
This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.
The following CodedUI Dlls are shipped with VS2012. What I did was just copy them to a separate folder and reference them from there. I checked the *.csproj file, it has the correct info as below. But in VS2012 property window, I checked the reference path, they are STILL resolved the default locations like "D:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ReferenceAssemblies\v4.0\Microsoft.VisualStudio.QualityTools.CodedUITestFramework.dll"
The works for only one of the following DLLs, the "Microsoft.VisualStudio.QualityTools.UnitTestFramework". But I don't see anything different between how this DLL is referenced and the others.
WTF is this happening?
I see some other guy reported a bug about VS 2012 assembly binding.(http://social.msdn.microsoft.com/Forums/en/vsunittest/thread/ba271f86-ed33-49a5-9b52-99980e88d198)
But I am using the RTM version!
<Reference Include="Microsoft.VisualStudio.QualityTools.CodedUITestFramework, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\Microsoft.VisualStudio.QualityTools.CodedUITestFramework.dll</HintPath>
</Reference>
<Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll</HintPath>
</Reference>
<Reference Include="Microsoft.VisualStudio.TestTools.UITest.Common, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\Microsoft.VisualStudio.TestTools.UITest.Common.dll</HintPath>
</Reference>
<Reference Include="Microsoft.VisualStudio.TestTools.UITest.Extension, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\Microsoft.VisualStudio.TestTools.UITest.Extension.dll</HintPath>
</Reference>
<Reference Include="Microsoft.VisualStudio.TestTools.UITesting, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\Microsoft.VisualStudio.TestTools.UITesting.dll</HintPath>
</Reference>
A ticket has been submitted to MS Connect: https://connect.microsoft.com/VisualStudio/feedback/details/758647/hintpath-in-csproj-file-doesnt-work-for-vs2012
I'm trying to build a Visual Studio add-in.
For long-winded reasons (to do with using disassembled assemblies courtesy of .NET Reflector) I removed the reference to the EnvDTE assembly, then re-added it. My project still builds without any problems but when I run my project I get the following exception.
System.IO.PathTooLongException occurred
Message=The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
Source=mscorlib
StackTrace:
at System.IO.PathHelper.GetFullPathName()
InnerException:
None of my references have particularly long paths - they're all the GAC and roughly the same length. I'm not trying to do anything different from before I had trouble with the EnvDTE assembly.
Does anyone have any ideas what might be causing this and how it can be resolved?
UPDATE:
My csproj file shows the following reference paths:
<ItemGroup>
<Reference Include="BoneSoft.CSS">
<HintPath>bin\BoneSoft.CSS.dll</HintPath>
</Reference>
<Reference Include="EnvDTE, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<EmbedInteropTypes>True</EmbedInteropTypes>
</Reference>
<Reference Include="Extensibility, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<EmbedInteropTypes>False</EmbedInteropTypes>
</Reference>
<Reference Include="HtmlAgilityPack">
<HintPath>bin\HtmlAgilityPack.dll</HintPath>
</Reference>
<Reference Include="Microsoft.VisualStudio.OLE.Interop, Version=7.1.40304.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<Reference Include="Microsoft.VisualStudio.Shell, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
<Reference Include="Microsoft.VisualStudio.Shell.Interop, Version=7.1.40304.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<Reference Include="microsoft.visualstudio.shell.interop.8.0, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<Reference Include="Microsoft.VisualStudio.Shell.Interop.9.0, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<Reference Include="System" />
<Reference Include="System.Core" />
<Reference Include="System.Data" />
<Reference Include="System.Windows.Forms" />
<Reference Include="System.Xml" />
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
Try opening up your .csproj in notepad and look at the Reference entries for all of your assemblies. What's almost certainly happened is they got added with a weird relative path that caused it to extend past the 260 character limit in the HintPath node.
To fix just delete the HintPath element, reload your project and the issue should go away. It isn't necessary for EnvDTE.
I had this problem too after updating references to Telerik assemblies in my Silverlight 5 project. After deleting the HintPath nodes as JaredPar suggested, my issue was resolved. I'm providing a screen shot here to show the broken version (on left) and the fixed version (on right). Thanks JaredPar... sorry I can't vote your answer up yet.
I met a problem which is very strange, my company uses Visual Source Safe
to control version,but I found that my team's different member see the same .csproj file in VSS is not the same, it's very strange,can you help me? thanks!!
there is a file named IPRA.WinUi.Sal.Sra.csproj in VSS:
when Tom log on ,the file 'IPRA.WinUi.Sal.Sra.csproj' is :
<Reference Include="Ark.Client.WinUi, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\ARAF\BusinessFramework\Ark.Client.WinUi.dll</HintPath>
</Reference>
<Reference Include="Ark.Common.Business, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL" />
<Reference Include="Ark.Controls.Business, Version=0.0.0.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\ARAF\SystemFramework\Ark.Controls.Business.dll</HintPath>
</Reference>
But when leo log on,the same file 'IPRA.WinUi.Sal.Sra.csproj' is :
<Reference Include="Ark.Client.WinUi, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\ARAF\BusinessFramework\Ark.Client.WinUi.dll</HintPath>
</Reference>
<Reference Include="Ark.Common.Business, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL" />
<SpecificVersion>False</SpecificVersion>
<HintPath>..\ARAF\BusinessFramework\Ark.Controls.WinUi.dll</HintPath>
<Reference Include="Ark.Controls.Business, Version=0.0.0.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\ARAF\SystemFramework\Ark.Controls.Business.dll</HintPath>
</Reference>
He needs to do a get latest, try build tree option to get to your development folder. He might be getting files to the wrong folder, thus his files are not updated. Try verifying your working folder is set correctly.
but I found that my team's different
member see the same .csproj file in
VSS is not the same,
Team see the same cs project? Then wats the issue?
If the team is seeing different file then the other person has not checked in or you are not using the latest version. Always try to checkin when you leave and get the latest version when you start your work.