locked
Building the project with Visual Studio 2013 installed RRS feed

  • Question

  • I am redirecting here from https://tfsintegration.codeplex.com because the page instructed me to do so.  I see a lot of retail users in this forum, but will assume this is still the right place for a developer also.

    I need some help.

    Currently, I have:

    Visual Studio 2008
    Visual Studio 2010
    Visual Studio 2012
    AND
    Visual Studio 2013
    AND
    Visual Studio 2015

    installed.  This is a pretty normal configuration for anyone who has an active MSDN account and a large trove of older projects at work.

    So here is my problem.

    I open version 65711 of the TFSIntegration project in Visual Studio 2010. 

    Let's cross all our I's and dot all our T's, lest I be peppered with obvious statements:  yes, I have run the \Development\setup_build_environment.bat file and yes, it has successfully and correctly constructed my \Binaries\Internal\TFS2008 and \Binaries\Internal\TFS2010 folders.  And yes, I have downloaded the SVN and APR sources and placed them at \IntegrationPlatform\ExternalSources\Subversion and \IntegrationPlatform\ExternalSource\APR respectively.   Additionally, I had to edit the properties of the Interop.Subversion project, and add the \IntegrationPlatform\ExternalSource\Subversion\Include folder manually (as an Include folder) because it did not pick it up automatically (nothing was required for the APR folder, but the instructions do not explicitly say to only copy over the Subversion/include folder).

    Anyways... I am honestly at a place, now, where the solution should build.  However... it fails, and upon closer inspection, what is happening is that for all of the TFS11 projects... the TFS11 references are somehow being automatically upgraded to TFS12 references.  This would not be so bad except that the base framework for TFS12 went up to 4.0, while TFS11 and below were all built on 2.0.  So making a 4.0 reference in a 3.5 targeted project, the reference is for obvious reasons failing.

    What is not obvious to me is why is the automagic upgrade is occurring at all from TFS11 references to TFS12 references.  I even went so far as to create a \Binaries\Internal\TFS2012 folder, and populate it with the TFS11 assemblies, and then directly reference those DLLs from the project with the Browse button, and yet, hocus pocus, even those kinds of references are being automatically upgraded (to the TFS12 copy found in the GAC).  I'm not really being given a chance to select Use Specific version, because the manual file specific reference doesn't show up as such, but is being "upgraded" before it ever gets added to the project.  What is more confusing, is why the upgrade is upgrading the DLLs to the V12, 4.0 framework copies, even though the project is targeted to 3.5.

    I'm not asking for a project update to include support for 2013.  I'm just asking if anyone can share with me how to prevent this automatic reference upgrading for the TFS assemblies so that TFS11 references STAY TFS11 references.  IF they do that, then I will be able to build this project without any troubles.

    I need to build the project so I can add some automatic rules to it (I'm surprised wild card rules weren't originally supported).  I have been tasked with migrating our source code store to VisualStudio.com and using the utility as it is is generating a "VC path not mapped" conflict type on what appears to be every folder and every file in old ghost Team projects in our current TFS 2010 installation (which itself was migrated from an earlier version of TFS 2008).  The ghost folders were in the TFS 2008 installation, but those Team Projects appear to have been dumped as things were migrated to TFS 2010, yet references appear to remain in the changesets that are triggering this "VC path not mapped" during the Analyze phase.  Stopping... adding the rule... and then restarting is just too time prohibitive (there will be many thousands of these things).  I need to modify the project so that it will continue all the way through the analyze phase, stacking up errors in the list box, and this will allow me to roll through them in a single pass and make rules from them, or better yet, modify it so I can create a single wildcard rule that will automatically apply to all of the errors of the particular type.

    Sure do hope at least one member of the original development team for this project is actually paying attention to these posts as is claimed on the Codeplex page.  I have run out of ideas to prevent the automatic upgrade, and yet my boss's boss expects us to be on VisualStudio.com by the end of the year.

    Ho ho ho.  Merry Christmas to me.  =)


    Thursday, December 24, 2015 4:03 AM

Answers

  • OK. I understand what the problem was now.  Good grief.  The problem was that the (using as an example) FileSystemAdapterForTfs11.csproj project is inheriting from the FileSystemAdapterForTFS2010 project.  In that project, the references for those DLLs are defined as:

    <HintPath>..\..\..\..\Binaries\Internal\TFS$(FileSystemTfsTarget)\Microsoft.TeamFoundation.Client.dll</HintPath>

    macros.  The value for FileSystemTfsTarget  in the FileSystemAdapterForTfs11 project is NOT set for "2012"... it is set to "11".

    Thus, my manually created \Binaries\Internal\TFS2012 folder did not work, and so it defaulted to the GAC (which has the most current version... version 12, for the 4.0 framework).

    As soon as I renamed my folder to TFS11, all of those issues went away and I could build (with a little more cleanup involved on the test project).

    That is what you call "a beating".  There is code in the extract_tfs_assemblies.bat batch file for creating a TFS11 folder.  I can't explain why it failed on my computer. Perhaps I did not run the batch file correctly. I'm not sure.

    Anyways... after resolving this issue, all of the other build issues were little by comparison and easily solved.

    So I am building and have a few days left to get this project done on time.  =)

    Monday, December 28, 2015 12:28 PM

All replies

  • Hi JeffTheDotNetGuy,

    By default, the higher version is compatible to the lower version. The TFS assemblies are installed and registered during VS installed and the assemblies are in the corresponding VS install folder (e.g. .. Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer), so it may update the necessary assemblies when upgrade the project/solution.

    >> I even went so far as to create a \Binaries\Internal\TFS2012 folder, and populate it with the TFS11 assemblies, and then directly reference those DLLs from the project with the Browse button

    Do you mean it still upgrade the reference after you reference the assembly files in that directory?

    It's better  and easy to deal with the incorrect references after project/solution upgrade.

    There are some links that may benefit you:

    # Upgrading Projects

    https://msdn.microsoft.com/en-us/library/bb166539(v=vs.120).aspx

    # Troubleshoot Unsuccessful Visual Studio Project Upgrades

    https://msdn.microsoft.com/en-us/library/ms185327(v=vs.120).aspxRegards

    Starain


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.



    Friday, December 25, 2015 8:11 AM
    Moderator
  • >> Do you mean it still upgrade the reference after you reference the assembly files in that directory?

    Yes.  Isn't that crazy? 

    You've used the word "upgrade" several times in your reply, but I have no interest in upgrading this project.  (To be clear, we are talking about this: https://tfsintegration.codeplex.com/ project, as downloaded).

    I'm going to try a couple more things this morning, but I may end up having to dump the TFS11 projects from the solution (if it will let me do that).

    Monday, December 28, 2015 11:56 AM
  • OK. I understand what the problem was now.  Good grief.  The problem was that the (using as an example) FileSystemAdapterForTfs11.csproj project is inheriting from the FileSystemAdapterForTFS2010 project.  In that project, the references for those DLLs are defined as:

    <HintPath>..\..\..\..\Binaries\Internal\TFS$(FileSystemTfsTarget)\Microsoft.TeamFoundation.Client.dll</HintPath>

    macros.  The value for FileSystemTfsTarget  in the FileSystemAdapterForTfs11 project is NOT set for "2012"... it is set to "11".

    Thus, my manually created \Binaries\Internal\TFS2012 folder did not work, and so it defaulted to the GAC (which has the most current version... version 12, for the 4.0 framework).

    As soon as I renamed my folder to TFS11, all of those issues went away and I could build (with a little more cleanup involved on the test project).

    That is what you call "a beating".  There is code in the extract_tfs_assemblies.bat batch file for creating a TFS11 folder.  I can't explain why it failed on my computer. Perhaps I did not run the batch file correctly. I'm not sure.

    Anyways... after resolving this issue, all of the other build issues were little by comparison and easily solved.

    So I am building and have a few days left to get this project done on time.  =)

    Monday, December 28, 2015 12:28 PM
  • Hi JeffTheDotNetGuy,

    I am glad to hear that the issue has been solved. Thanks for sharing the solution. You could mark it as answer.

    Regards

    Starain


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, December 29, 2015 5:45 AM
    Moderator