none
Build fails due to not finding project in solution

    Question

  • I have a build that is named like the following:

    CompanyName.Services.ServiceName, when running the build with this name everything works as expected, but if I remove the CompanyName the build fails with the following error:

    File.cs (line): The type 'type' is defined in an assembly that is not referenced. You must add a reference to assembly 'assembly, version, culture, PublicKeyToken'.

    I get 4 or 5 of those errors (Depending on the build) and then I get:

    C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (1200): The referenced project 'ProjectForAboveAssembly.csproj' does not exist.

     

    Usually I fix the missing project by shorting the path of the solution, either the work space destination or the name of the solution, as I always assumed the above was due to a limitation in the path size in Visual Studio/MSBuild, but in this case shorting the path causes the issue as the longer path name succeeds.

    Using the build with the short/broken name I open the solution on the build machine in Visual Studio and it is able to load the project, but when I build the solution MSBuild states it can not find the project.

     

    As stated above I used to think this was due to a path size limit, but given the shorter path breaks I'm lost on what the issue would be, I know I could just keep the longer name, but we strive to keep a consistant naming in our builds. However, given that it may not be a path size, once I figure out the issue I may rename all our builds back to including the company name prefix as that is really prefered.

     

    Any help would be greatly appreciated.

    Tuesday, January 31, 2012 3:09 PM

All replies

  • Hi ThisByte5,

    Thank you for your question.

    I am currently looking into this issue and will give you an update as soon as possible.
     
    Thank you for your understanding and support.


    Cathy Kong [MSFT]
    MSDN Community Support | Feedback to us
    Wednesday, February 01, 2012 9:13 AM
    Moderator
  • It's not clear from where did you remove the CompanyName - from the namespace? from the assembly name? or project name?

    In any case, open your ProjectForAboveAssembly.csproj and check that RootNamespace and AssemblyName are what you want.

     

        <RootNamespace>CompanyName.Services.ServiceName</RootNamespace>
        <AssemblyName>CompanyName.Services.ServiceName</AssemblyName>
    


     

    Wednesday, February 01, 2012 12:23 PM
  • I removed teh CompanyName from the Build Definition name.
    Wednesday, February 01, 2012 1:00 PM
  • By default the build definition name itself does not play a role in the build process apart from assigning a logical name.

    Did you change the template (DefaultTempate.xaml)?

    Wednesday, February 01, 2012 2:26 PM
  • Yes I did change the default template, but the change works just fine for all the builds we have except for a couple of builds. 

    Company.AppType.Project <-- This works
    AppType.Project <-- This fails with the error specified above

    Though I understand and agree that the build definition name doesn't play a role in the build process, it obviously is affecting the build in question some how. I've written a tool to create our builds based on the solution loaded, and if I recreate the build in both scenerio's above I get the same results, given the code is creating the build I'm a 100% positive that the build definitions are identical with the exception of the names. 

    Also since the build definition name is used in the path (folder names) for the build when it runs, I always assumed it was hitting a file name length issue, but as I stated above the longer name works and the shorter name doesn't, usually when I see this issue I shorten the build name and the issue goes away, so I'm now really stumped as to why it's failing with this error as it shouldn't be a path issue.

    Thursday, February 02, 2012 6:56 PM
  • This is very interesting. I suggest to try a build with the failing build definition with the original default template. I can't think of a reason the build name itself breaks the referencing.
    Thursday, February 02, 2012 11:07 PM
  • Hi,

    As per the error message, File.cs is not able to load the referenced object from the renamed project. You might need to update the namespace on File.cs to incorporate the updated namespace


    Regards,
    Adhi
    TFS/ALM Lead
    My TFS Blog
    Thursday, February 02, 2012 11:26 PM
  • Hi ThisByte5,

    Is the issue solved?

    I am marking Adhithan's reply as answer, if you have any concern with it, please feel free to unmark it.

    Best Regards,


    Cathy Kong [MSFT]
    MSDN Community Support | Feedback to us

    Tuesday, February 07, 2012 1:33 AM
    Moderator
  • No the issue is not resolved, as stated the build WORKS if the build definition name is LONGER version of the name, but does NOT work if it's shorter. The issue is WHY does it work one way but not the other?
    Tuesday, February 07, 2012 12:04 PM
  • Could you provide both sthe creenshots of where you made changes to make the build succeed and fail?

    Also the error log from buildlog.txt


    Regards,
    Adhi
    TFS/ALM Lead
    My TFS Blog

    Tuesday, February 07, 2012 7:18 PM
  • Following is the working edit:

    Following is the NON working edit:

    This is the Build Def Name that does not work

    As for the error log from the build log I assume you mean just the errors not the entire log, notice the section in bold, says it can not find the project:

    C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (1200): The referenced project '..\..\Leads.Shared.Model.Validation\Leads.Shared.Model.Validation\Leads.Shared.Model.Validation.csproj' does not exist.
     AvailableLoadsController.cs (1054): 'Leads.AvailableLoads.Controller.AvailableLoadsController.GetTractorsByOwnerName(string, int, int, int)' hides inherited member 'Leads.Shared.Controller.LoadsController.GetTractorsByOwnerName(string, int, int, int)'. Use the new keyword if hiding was intended.
     AvailableLoadsController.cs (1068): 'Leads.AvailableLoads.Controller.AvailableLoadsController.GetTractorDetailByTractorNumber(int)' hides inherited member 'Leads.Shared.Controller.LoadsController.GetTractorDetailByTractorNumber(int)'. Use the new keyword if hiding was intended.
     AvailableLoadsController.cs (110): Missing XML comment for publicly visible type or member 'Leads.AvailableLoads.Controller.AvailableLoadsController.GetPermitAccessorials(int, string)'
     AvailableLoadsController.cs (168): Missing XML comment for publicly visible type or member 'Leads.AvailableLoads.Controller.AvailableLoadsController.GetLoadDirectFromSvc(Leads.Shared.Model.LoadKey)'
     AvailableLoadsController.cs (301): The type 'Leads.Shared.Model.Validation.BaseLoad' is defined in an assembly that is not referenced. You must add a reference to assembly 'Leads.Shared.Model.Validation, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cef266d3e6fc9594'.
     AvailableLoadsController.cs (301): 'Leads.Shared.Model.Validation.BaseLoad' does not contain a definition for 'HasErrors' and no extension method 'HasErrors' accepting a first argument of type 'Leads.Shared.Model.Validation.BaseLoad' could be found (are you missing a using directive or an assembly reference?)
     AvailableLoadsController.cs (407): 'Leads.Shared.Model.Validation.BaseLoad' does not contain a definition for 'HasErrors' and no extension method 'HasErrors' accepting a first argument of type 'Leads.Shared.Model.Validation.BaseLoad' could be found (are you missing a using directive or an assembly reference?)
     AvailableLoadsController.cs (459): 'Leads.Shared.Model.Validation.BaseLoad' does not contain a definition for 'HasErrors' and no extension method 'HasErrors' accepting a first argument of type 'Leads.Shared.Model.Validation.BaseLoad' could be found (are you missing a using directive or an assembly reference?)
     AvailableLoadsController.cs (990): The type 'Leads.Shared.Model.Validation.CustomerRateConfirmation' is defined in an assembly that is not referenced. You must add a reference to assembly 'Leads.Shared.Model.Validation, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cef266d3e6fc9594'.
     AvailableLoadsController.cs (990): 'Leads.Shared.Model.Validation.CustomerRateConfirmation' does not contain a definition for 'HasErrors' and no extension method 'HasErrors' accepting a first argument of type 'Leads.Shared.Model.Validation.CustomerRateConfirmation' could be found (are you missing a using directive or an assembly reference?)
     AvailableLoadsStateProps.cs (62): Missing XML comment for publicly visible type or member 'Leads.AvailableLoads.Controller.AvailableLoadsStateProps.PermitAccessorials'
     AvailableLoadsStateProps.cs (151): Missing XML comment for publicly visible type or member 'Leads.AvailableLoads.Controller.AvailableLoadsStateProps.NonEditableLoad'

    Wednesday, February 08, 2012 12:16 PM
  •  

    Hmm... this is strange.

    The error clearly says that build is not able to load the “Leads.Shared.Model.Validation.csproj'” file. This error might not be related to build definition name changes.

    Just to make things clear.

    Could you delete/Clean the (temporary) build directory of AVTrucks-CompanyName.Leads.AvailableLoads build on the Build server and queue a new build?


    Regards,
    Adhi
    TFS/ALM Lead
    My TFS Blog

    Wednesday, February 08, 2012 7:04 PM
  • I’ve done that many times before the initial post, I’ve even deleted the build definition and recreated it with both names from scratch. As mentioned in my reply on February 2<sup>nd</sup> I have a tool that creates our builds, I modified it to create it with both names, and the longer name works, but the shorter name does not. I’ve also found two other builds that are failing due to the name change, but the other 8 builds for Leads build just fine with either name, most of which use the Leads.Shared.Model.Validation.csproj in the solution.

    If I open the solution in Visual Studio from the build directory I get the same error when I build it, but I am able to see the project in the solution explorer no problem.

    Also from a command prompt I've gone to the directory with the solution file, and did a DIR of the project using the path that is in the solution, the project file in question is found in this scenerio so I know the paths are correct given the current directory structure. I also did this as well with the project that is reporting it can not find the Validation project.

    Thursday, February 09, 2012 1:16 PM
  •  

    It is an interesting problem. We should be able to fix this issue, if I have more detail on this.

    On the build machine when you opened this solution, did you verify all the reference assemblies have been loaded correctly for all the projects associated with this solution?

    Could you provide the compile (errors and warning) log?


    Regards,
    Adhi
    TFS/ALM Lead
    My TFS Blog

    Thursday, February 09, 2012 3:53 PM
  • Yes everything was good, all refs were fine no yellow exclamation marks.
    I've provided the Errors from the errors window, there are 2321 warnings so I didn't provide them here, though if you do really need them I will spend some time cleaning up the projects to get them manageable to be able to post, most of the errors are due to a lack of xml documentation, obsolete properties, etc… Most of which I can suppress or remove the cause.

    Error 17 Metadata file 'D:\Builds\11\AVTrucks\AVTrucks-Leads.AvailableLoads\Sources\CompanyName.Leads.AvailableLoads\CompanyName.Leads.AvailableLoads.Controller\bin\Debug\CompanyName.Leads.AvailableLoads.Controller.dll' could not be found CompanyName.Leads.AvailableLoads.Presenter

    Error 18 Metadata file 'D:\Builds\11\AVTrucks\AVTrucks-Leads.AvailableLoads\Sources\CompanyName.Leads.AvailableLoads\CompanyName.Leads.AvailableLoads.Controller\bin\Debug\CompanyName.Leads.AvailableLoads.Controller.dll' could not be found CompanyName.Leads.AvailableLoads.Tests.Presenter

    Error 19 Metadata file 'D:\Builds\11\AVTrucks\AVTrucks-Leads.AvailableLoads\Sources\CompanyName.Leads.AvailableLoads\CompanyName.Leads.AvailableLoads.Presenter\bin\Debug\CompanyName.Leads.AvailableLoads.Presenter.dll' could not be found CompanyName.Leads.AvailableLoads.Tests.Presenter

    Error 20 Metadata file 'D:\Builds\11\AVTrucks\AVTrucks-Leads.AvailableLoads\Sources\CompanyName.Leads.AvailableLoads\CompanyName.Leads.AvailableLoads.Presenter\bin\Debug\CompanyName.Leads.AvailableLoads.Presenter.dll' could not be found CompanyName.Leads.AvailableLoads.Tests.DefectResolution

    Error 21 Metadata file 'D:\Builds\11\AVTrucks\AVTrucks-Leads.AvailableLoads\Sources\CompanyName.Leads.AvailableLoads\CompanyName.Leads.AvailableLoads.Controller\bin\Debug\CompanyName.Leads.AvailableLoads.Controller.dll' could not be found CompanyName.Leads.AvailableLoads.Tests.DefectResolution

    Thursday, February 09, 2012 6:23 PM
  •  

    Ok. One more attempt to find the issue

    Are these following references, referenced as assemblies or projects?

    CompanyName.Leads.AvailableLoads.Presenter

    CompanyName.Leads.AvailableLoads.Tests.Presenter

    CompanyName.Leads.AvailableLoads.Tests.DefectResolution

    Do you see these references on CompanyName.Leads.AvailableLoads.Controller project?

    Also, could you verify the whether the project reference path are relative path or absolute path in solution file?

    If this did not give any clue for the resolution, you might need to open up service ticket with Microsoft to take a look at your builds.


    Regards,
    Adhi
    TFS/ALM Lead
    My TFS Blog

    Thursday, February 09, 2012 9:00 PM
  • They are all project references, the AVLoads.Presenter shows the controller as a yellow exclamation mark. However, if you look at my post on Feb 8th, you'll see that the errors listed from the automated build are differnt then the errors listed by visual studio which are in my 2nd post on feb 9th.

    All paths are relative.

    In a command prompt I go to the directory where the presneter project is located and do a DIR of the relative path, it finds the project just fine.

    So I'm very confused now.

    Friday, February 10, 2012 12:29 PM
  •  

    Now we see a reference error, this is want we need to find out.

    Ok. One more attempt. I still believe this build is missing the references (dependent assemblies).

    I assume you opened the solution from build (temp) directory on the build machine. And you saw the missing references.

    Is that right?

     If yes then find out what are references missing and its dependency assemblies. Expand all the references (and type of references) to find out the missing references.


    Regards,
    Adhi
    TFS/ALM Lead
    My TFS Blog

    Friday, February 10, 2012 10:28 PM
  • Yes I opened the build from the build temp directory, and the missing refs are project assemblies.

    However, remember that with a longer build def name the code builds just fine, and when I open the solution in the temp build dir with the longer name it compiles in VS just fine. There are NO code changes here.

    Monday, February 13, 2012 12:34 PM