I'm upgrading a Visual Studio solution from 2008 to 2013. Due to licencing issues I'll be using msbuild.exe, instead of devenv.com, on our build servers.
But I've hit a linking error which appears to be specific to msbuild.exe. i.e. When built with devenv.com there is no issue.
Debugging into the problem I discovered a difference between the link commands. The project (testA) that gives the error depends upon a project (projectA). This dependency is setup in the Visual Studio 2013 Project Dependencies/Project References.
But we don't want testA to use this approach to link against projectA (we have an alternative mechanism to do the linking). So the Link Library Dependencies attribute of Project Reference Properties is set to False. In the .vcxproj that looks like
<ProjectReference Include="..\..\projectA.vcxproj">
<Project>{472cd426-5c95-4f53-97f8-bf7c4425d1d4}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
<Private>true</Private>
<CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
<LinkLibraryDependencies>false</LinkLibraryDependencies>
<UseLibraryDependencyInputs>false</UseLibraryDependencyInputs>
</ProjectReference>
For Visual Studio 2013 (aka devenv.com) that is fine. projectA is not linked.
But msbuild.exe does not respect this property. On the command line I see it link with projectA.lib. That gives the following error
error LNK2005: "public: bool __thiscall projectA::mymethod(void)const "
(?ismethod#projectA##QBE_NXZ) already defined in myobject.obj
Is this a known issue. Is there a workaround?
Related
I have a project which I am using as a simple testbed for a graphical application. I am attempting to add a shared project file (.shproj), but whenever I try to edit the project's dependencies, I get a dialog which says:
---------------------------
Microsoft Visual Studio
---------------------------
String value '
' cannot be translated to any value from type System.Guid.
---------------------------
OK
---------------------------
This happens if I right-click on my project and select either **Add Project Reference..." or "Add Shared Project Reference..."
Unfortunately I do not have this project as part of source control so I can't go back in time to see what may have caused this problem. I have attempted to undo the operations which may have gotten me into this state (such as adding the .shproj to my solution) but the dialog still appears when I attempt to edit the dependencies.
I haven't been able to find anything online about this error, and I suspect it's happening because something is malformed in either my .csproj or the .sln, but I'm not sure where to look or what to try to solve this.
I am running Visual Studio 2022 (17.4.2).
I have tried opening the project in Visual Studio 2019 and I can edit the dependencies there. I can also add and remove nuget packages. Note that if I modify the dependencies in Visual Studio 2019, the project will correctly load and build in 2022 so I do have a workaround. However, it would be nice to know why the project dependencies cannot be edited in 2022.
It turns out that empty Project tags caused problems in the .csproj file.
My .csproj file referenced other .csproj files and these references included empty Project tags.
Here is a snippet before the fix:
<ProjectReference Include="../../../GitHub/FlatRedBall/Engines/FlatRedBallXNA/FlatRedBallDesktopGLNet6/FlatRedBallDesktopGLNet6.csproj">
<Name>FlatRedBallDesktopGLNet6</Name>
<Project>
</Project>
</ProjectReference>
Removing the Project tags solves this problem, as shown in the following code:
<ProjectReference Include="../../../GitHub/FlatRedBall/Engines/FlatRedBallXNA/FlatRedBallDesktopGLNet6/FlatRedBallDesktopGLNet6.csproj">
<Name>FlatRedBallDesktopGLNet6</Name>
</ProjectReference>
I've a problem with a build with TFS 2015.
I've a simple project that reference B.dll . B.dll use A.dll . The project don't reference A.dll as it don't use it itself.
A.dll & B.dll bothe are company Framework dll stored in the GAC.
[error]LogistiqueTest\Index.aspx.vb(7,14): Error BC30009: Reference required to assembly 'A.DII.Technique.Interfaces, Version=3.5.0.0, Culture=neutral, PublicKeyToken=e60618ca32d203a8' containing the implemented interface 'A.DII.Technique.Interfaces.IGestionException'. Add one to your project.
This is not a big deal, just a reference that's missing. But we don't want to add unecessary references in our projects
Moreover, this problem don't occurs with visual studio (2013 pro)
So I tracked the problem and I saw that :
-> Visual studio retrieve quickly the reference (A.dll) after the "call" of this line
Target "CoreBuild: (TargetId:61)" in file "C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets" from project "D:\AgentTFS_02_work\3\s\LogistiqueTest\LogistiqueTest.vbproj" (target "Build" depends on it):
But TFS don't use the same file; it use
"C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets"
The difference between those files is in Microsoft.Common.CurrentVersion.targets, there is some code for resolving assemblies.
So my questions are, is there a way to make TFS build my solution visual studio like ? Force the other target file to be used? Is there another trick to be able to resolve this assembly ?
I tried to add, like i saw in many post around the web, a folder that contains every .dll required, but TFS don't event try to resolve path for A.dll
More information : The exception occurs at the execution of Vbc.exe
because with VS execution the command line has A.dll in the /import section when with TFS it's not added. No problems with MSBuild.exe.
I finally found an anwser :
http://www.nsilverbullet.net/2012/02/17/automatically-resolving-secondary-assembly-references-with-msbuild-and-tfs-build/
I need to add this to the proj file that has problems.
<Target Name="AfterResolveReferences">
<!-- Redefine referencepath to add dependencies-->
<ItemGroup>
<ReferencePath Include="#(ReferenceDependencyPaths)"></ReferencePath>
</ItemGroup>
</Target>
I am attempting to add a custom “activitycode” to a TFS Build. I wrote this months ago and had it working on a now defunct test environment. I am attempting to resurrect the use of the code onto a new test platform, and am running into issues.
When I open my build.xaml, I receive the dreaded red-box of pain where my custom activity should be, stating “Assembly could not be loaded because of an error in the XAML.” In the ErrorList, I also have found “Could not find type '.DeploySSRSReportActivity' in assembly 'ReportingServicesDeploy'.”
I have confirmed that my DLL is checked into source control and that the build controller is pointing to it.
Peeking into the raw XAML, I see that the build.xaml file defines the assembly as
xmlns:rsd="clr-namespace:;assembly=ReportingServicesDeploy
The line where my custom activity (and where V.S. finds the error) is:
<rsd:DeploySSRSReportActivity CurrentBuild="[BuildDetail]"
SourcesDirectory="[SourcesDirectory]"
mtbwt:BuildTrackingParticipant.Importance="High"
xmlns:mtvc="clr-namespace:Microsoft.TeamFoundation.VersionControl.Client;assembly=Microsoft.TeamFoundation.VersionControl.Client"
xmlns:mtvco="clr- namespace:Microsoft.TeamFoundation.VersionControl.Common;assembly=Microsoft.TeamFoundation.VersionControl.Common"
xmlns:ras="clr-namespace:ReportingServicesDeploy;assembly=ReportingServicesDeploy"
xmlns:rsd="clr-namespace:;assembly=ReportingServicesDeploy"
xmlns:sad="http://schemas.microsoft.com/netfx/2009/xaml/activities/presentation"
xmlns:sad1="clr-namespace:System.Activities.Debugger;assembly=System.Activities" />
The DLL is named ReportingServicesDeploy.dll. The namespace within the DLL is ReportingServicesDeploy, and the name of the activity class is DeploySSRSReportActivity.
Where is the linkage failing so that I am getting that error?
When your attempting to edit the xaml your doing this on your machine directly, tfs and sourcecontrol is not involved, the location on server for controller is where build agent will look for assemblies during the build and where VS will get them when opening build definition for config.
Your error possibly is coused by old version being used.
The assemblies must be available for visual studio on your machine - one option is to add them to GAC or to post in VS bin folders. Start new instance of studio afterwards
To intall into GAC run this from Visual Studio command line:
gacutil /i "Path\To\YourAssembly.dll"
To remove assembly run following from Visual Studio command line:
gacutil /u "YourAssembly"
For studio assemblies i believe this is the folder:
Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies
Have been trying to build a solution which contains a number of projects and keep getting a recurring error.
I have managed to get the build to partially succeed but always get the error shown below:
C:\Builds\1\MBS.Payments.Forms.Mvc\MBS Payment Forms MVC\Sources\MBS.Payments.Forms.Mvc\MBS.Forms.Payments.Web\MBS.Forms.Payments.Web.csproj (979): The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
I have navigated to the file in which the error is being generated where this code is highlighted:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
Currently I have both Visual Studio 2010 Premium and a evaluation version of Visual Studio 2012 Ultimate installed, I am currently working on this application in Visual Studio 2010.
below is the code block in which the erroneous code is found:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
Please could anyone advise on why this error is being generated and how it could be resolved.
Check the two locations:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications
and
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications
Do either of these have the .targets file present? Personally I find it in both, but I'm guessing you don't (at least according to the error it's not in the v11.0 folder).
Your condition checks for VisualStudioVersion and VSToolsPath properties to see if they are missing, then sets them. One or both of these must be set already or it would be pointing to the v10.0 folder.
According to http://blogs.msdn.com/b/webdev/archive/2012/08/22/visual-studio-project-compatability-and-visualstudioversion.aspx, this is probably caused by opening the project in VS2012.
To fix, I'd either get a v11 copy of the .targets (there are some changes between the two from what I can see, maybe it wasn't correctly installed when you did the setup?) or revert to using the v10 version.
If using Visual Studio 2013 or newer and TFS 2010, you can edit your Build Definition to include a new MSBuild argument.
/p:VisualStudioVersion=10.0
As CryoFusion87 pointed out, the solution that worked for me was to remove the whole <PropertyGroup></PropertyGroup> tag and its content.
This tag is added to support opening projects from VS 2010 and VS 2012. See more in here: http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx
I am now using VS 2013 and this is not needed.
the <PropertyGroup></PropertyGroup> tag gets added to the project file when you open it in Visual Studio 2012, I was able to open the project file in a text editor, remove the PropertyGroup and it built successfully
I bumped into a strange situation with MSBuild just now. There's a solution which has three projects: LibX, LibY and Exe. Exe references LibX. LibX in its turn references LibY, has some content files, and also references to a third-party library (several pre-built assemblies installed in both GAC and local lib folder). The third-party library is marked as "Copy Local" ("private") and appears in the output of the LibX project, as the LibY's output and LibX's content files do. Now, Exe project's output has LibX project output, content files of the LibX project, LibY project output (coming from LibX), but NO third-party library's assemblies.
Now I worked this around by referencing the third-party library directly in Exe project, but I don't feel this is a "right" solution.
Anyone had this problem before?
There is a difference in behavior when building with MSBuild (i.e. command line, TFS Build and other tools) compared to building with Visual Studio. The secondary references are not included in the references variable sent into MSBuild compile tasks.
There are several extension points provided by MSBuild to change how references are to be resolved. I have successfully used AfterResolveReference to fix this issue for some of my projects - I have posted more info about the background on my blog.
The workaround is to add the following code into you vbproj or csproj files
<Target Name="AfterResolveReferences">
<!-- Redefine referencepath to add dependencyies-->
<ItemGroup>
<ReferencePath Include="#(ReferenceDependencyPaths)">
</ReferencePath>
</ItemGroup>
</Target>
Microsoft has stated that this is a won't fix on Connect
You can actually go into the Microsoft.CSharp.targets or Microsoft.VisualBasic.targets file (located in the framework directory, usually C:\Windows\Microsoft.NET\Framework\v3.5) and modify the csc or vbc task parameters to include additional reference dependencies. In the file (VB targets, line 166; C# targets, line 164) change:\
References="#(ReferencePath)"
to
References="#(ReferencePath);#(ReferenceDependencyPaths)"
This might cause other issues depending on how complicated things are and it may play tricks with the Visual Studio inproc compiler, but it's the only way to do it in MSBuild that I've found.
josant's answer almost worked for me; I kept getting an error in Visual Studio when I tried that:
A problem occurred while trying to set the "References" parameter for the IDE's in-process compiler. Error HRESULT E_FAIL has been returned from a call to a COM component
The solution to my problem was to put a condition on the ItemGroup, like this:
<Target Name="AfterResolveReferences">
<!-- Redefine referencepath to add dependencies-->
<ItemGroup Condition=" '$(BuildingInsideVisualStudio)' != 'true' ">
<ReferencePath Include="#(ReferenceDependencyPaths)"></ReferencePath>
</ItemGroup>
</Target>
That caused Visual Studio to ignore the reference change completely, and the build works fine locally and on the build server.
Yes, I've had that problem, too. Though I'd love to say otherwise, I believe you must include all transitive dependencies as references in your build file.
I've combined Alex Yakunin's solution with one that will also copy native dll's.
The AfterResolveReferences method fails if you've got a directed graph not a tree with a "trying to deploy different copies of the dll" error. (cf. How to configure msbuild/MSVC to deploy dependent files of dependent assemblies)