How to configure TeamCity to build a solution with 2 projects?
I have configured TeamCity to build my solution which has 1 project which is chosen as Startup Project and it builds fine.
I configured it by adding a new Build Step with Runner Type of "Visual Studio (sln)" from its WebUI.
I added a new class library project and added a reference to it from the first project and it builds fine locally.
The .csproj file of the first project now contains this:
<ItemGroup>
<ProjectReference Include="..\ClassLibrary1\ClassLibrary1.csproj">
<Project>{00E69E26-2576-4B9A-9180-CB1877B1D951}</Project>
<Name>ClassLibrary1</Name>
</ProjectReference>
</ItemGroup>
I checked in the code and teamcity fails to build!
error CS0246: The type or namespace name 'ClassLibrary1' could not be found (are you missing a using directive or an assembly reference?)
TeamCity seems to only build the startup project not the ClassLibrary1 although it's referenced.
How could I configure it to build my solution?
Would this be possible using the WebUI or I should be writing e.g. MSBuild scripts?
Thanks,
Team City handles .sln files, so you should not have any problems with mutliple projects.
Make Team City build the .sln files, not a csproj.
If it's already ok, check your reference to see if it points to the project within the solution or if it refers to the assembly file (might cause problem if you change your build configuration for example)
Your reference should look like this
<ProjectReference Include="..\ClassLibrary1\ClassLibrary1.csproj">
<Project>{some guid identifying your project}</Project>
<Name>ClassLibrary1</Name>
</ProjectReference>
To have this result, the reference should be made by right clicking a project on solution explorer, choose add reference and go to the Project section
Actually, the problem was TeamCity was caching because and the solution was to check the below check box from the Version Control Settings:
Agent checkout: Enforce overwrite all files
The reason it was caching was that I'm using the Checkout mode of "Automatically on server" which means it will cache: http://confluence.jetbrains.net/display/TCD65/VCS+Checkout+Mode
Related
I have a Visual Studio solution with the project I am working on (main project). The solution references a different project that main project requires as a dependency (dependency project).
The solution and the main project are located in one directory:
/mycode/main_project/main_project.sln
/mycode/main_project/main_project.csproj
The dependency project is located in a different directory:
/mycode/dependency_project/dependency_project.csproj
Both of these projects are under source control. I want to create some kind of configuration file for main project that is not under source control, so that another developer could clone both projects wherever they want and simply edit a non-source-controlled configuration file to allow the main project's solution to locate dependency project.
Currently, main solution locates dependency project using a relative path:
../dependency_project/dependency_project.csproj
If I enforce that all developers should clone these two projects to the same directory, the main solution will successfully link to the dependency project and everything will be happy. However, I would prefer that another developer can place the dependency project wherever they want.
Does Visual Studio 2019 Community support any kind of solution configuration file which could be kept ignored by version control and used to resolve the path to the dependency project?
Solution files are very primitive and do not offer such a dynamic functionality. However, if you don't need dependency_project to show up in the IDE, you can still reference it from main_project.csproj and that does give you more options. It should still build fine even if the project doesn't show up in Solution Explorer.
For example, you could reference it through an environment variable, with a default expected path if that variable isn't set:
<PropertyGroup>
<DependencyProjectPath Condition=" '$(DependencyProjectPath)' == ''>../dependency_project/dependency_project.csproj</DependencyProjectPath>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="$(DependencyProjectPath)" />
</ItemGroup>
If you set the DependencyProjectPath environment variable before opening the solution (because VS inherits the environment variables from where it was launched), it will override the default setting here (based on the Condition attribute).
I have a Visual Studio 2010 C++ solution with two projects: an executable and a library. I am successfully able to delete project configurations from Configuration Manager for one of the projects (executable), but not the other (library).
Both projects were previously part of a vs2008 solution that have since been upgraded to vs2010.
When I try to delete a configuration from the library project, I get the error:
The operation could not be completed. Invalid pointer.
This happens for all configurations for that project.
Since this happens with only one of the projects, it leads me to believe that there is probably something wrong with the project and that's why VS2010 doesn't like it. Any ideas what may be wrong?
After some trial and error, I found that the problem was with some left-over project configuration in the library project file (library.vcxproj). The offending section was:
<ProjectExtensions>
<VisualStudio>
<UserProperties RESOURCE_FILE="library.rc" />
</VisualStudio>
</ProjectExtensions>
After deleting the section above from the project file and reloading the solution, I was able to delete project configurations.
I am trying to get our continuous integration server (cruise control .net) working with our solution. From cruisecontrol i call msbuild to build the solution and i'm running in some problems, let me explain the structure of the solution:
4 Projects:
DataAccess
BusinessEntity
BusinessLayer
(Project A)
Project A is the actual project with all the user forms etc.
This project has references to the other 3 projects.
When compiling in Visual Studio, everything works of course..
From what i understand is that MSBuild works quite different from VS.
When building project A with msBuilds i get the following error:
C:\CI\Project A\Source\Project A\General.vb(859,33): error BC30007: Reference required to assembly 'System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' containing the base class 'System.EnterpriseServices.ServicedComponent'. Add one to your project. [C:\CI\Setra\Source\Project A\Project A.vbproj]]]></message>
The funny thing is that Project A has no reference at all to the mentioned assembly. But the referenced DLL's in project A do have.
When i compile the other projects (those that generate the DLL's) with msbuild, the build succeeds.
I have the feeling it has something to do with the way the DLL's are referenced in the main project, but i can't seem to figure it out..
Any help or suggestions is greatly appreciated !!
This blogpost, despite being quite old, should answer your question. Some more useful info on how to approach this problem can be also found here.
In general, MSBuild has problems resolving secondary, ternary etc. references directly. More up to date article can be found here. I haven't tested this approach, though it seems quite good and easy to implement at the first sight:
Paste the following code into the file before the last tag:
<Target Name="AfterResolveReferences">
<!-- Redefine referencepath to add dependencies-->
<ItemGroup>
<ReferencePath Include="#(ReferenceDependencyPaths)"></ReferencePath>
</ItemGroup>
</Target>
This may be the issue
Project A is the actual project with all the user forms etc.
it has references to 3 DLL's which are created by the other projects.
In Solution Explorer, right click References and add a new Reference.
Do not browse for the dependency under Assemblies, instead go to Projects, Solution, choose the DataAccess, BusinessLayer, and BusinessEntity projects.
Now remove the File references & save the project file. When you rebuild, msbuild will detect these ProjectReference dependencies
I have an ASP.NET MVC 4 app developed in VS 2012. The app consists of a main project (MyProject), a unit-test project (MyProject.Tests), an Azure deployment project (MyProject.Azure), and a couple of general-purpose library projects.
When I right-click on either the solution or the main project and select Manage NuGet Packages, I see a bunch of Microsoft updates that have apparently become available in the last month or so. If I click on the Update All button then the updates are apparently installed without any obvious problems, but when I build the solution I get this error message TWICE:
warning : All projects referencing MyProject.csproj must install nuget package Microsoft.Bcl.Build
Ok, so I have two projects that reference MyProject: MyProject.Tests and MyProject.Azure. I can right-click MyProject.Tests, select ManageNuGet Packages, and add Microsoft.Bcl.Build. That gets rid of one of the two warnings. But VS does not give me an option to manage NuGet packages for the MyProject.Azure project.
How do I add the Microsoft.Bcl.Build package to the Azure deployment project?
EDIT:
Thanks to user swell, I now know that a Microsoft Connect issue for this problem has been opened here.
The answer provided by TheESJ is correct, however the wording wasn't clear to me. Since I cannot comment on the answer, I will provide more details here. Specifically, I was having this problem with an Azure project and the following workaround was required to make the warning go away:
When you double-click the warning in VisualStudio, you will be taken to the BclBuildValidateNugetPackageReferences target in the Microsoft.BclBuild.targets file. Above the actual target element, you should find a large comment block that talks about disabling the project reference checks. Since Azure projects cannot have any library references, it is impossible for those Azure projects to fulfill the requirements of this particular build target.
The solution? Disable reference checking from the Azure project since it is impossible to actually add a nuget package reference.
EXAMPLE
So, assume we have two projects: MyAzureProject.ccproj which references MyProject.csproj. Follow these steps:
Right-click on "MyAzureProject" in the Solution Explorer and select "Edit Project File."
Find the project reference to "MyProject." It should look something like:
<ProjectReference Include="..\MyProject\MyProject.csproj">
<Name>MyProject</Name>
<Project>{1d99490e-d140-4897-9890-238e673a5864}</Project>
...
</ProjectReference>
Add the following element inside of the ProjectReference element:
<Properties>SkipValidatePackageReferences=true</Properties>
Your project reference should now look like this:
<ProjectReference Include="..\MyProject\MyProject.csproj">
<Name>MyProject</Name>
<Project>{1d99490e-d140-4897-9890-238e673a5864}</Project>
...
<Properties>SkipValidatePackageReferences=true</Properties>
</ProjectReference>
Right-click on "MyAzureProject" in Solution Explorer and choose "Reload Project."
You should now be able to rebuild and the error should be gone.
If you double click the warning it gives you instructions for disabling the warning.
It is safe to disable for projectreferences from projects that don't yet support Nuget.
See below portion in bold copied from Microsoft.Bcl.Build.targets.
BclBuildValidateNugetPackageReferences
This target can be disabled for a project reference by setting SkipValidatePackageReferences=true for the reference:
<ProjectReference Include="..\pcl\pcl.csproj">
<Project>{664a9e98-fac7-4567-a046-0dde95fddb48}</Project>
<Name>pcl</Name>
<Properties>SkipValidatePackageReferences=true</Properties>
</ProjectReference>
I faced the same issue and was trying to update Microsoft.Bcl.Build.targets; which did not help.
After some investigation found that .csproj file of the Azure Service project must be modified to include <Properties>SkipValidatePackageReferences=true</Properties>.
This was not apparent from the answer of #TheESJ and so decided to post separate answer. Thanks to #TheESJ.
I encountered this issue a number of times, and the Properties method does indeed work, but when dealing with a Wix project, I had to do the following instead:
<AdditionalProperties>SkipValidatePackageReferences=true</AdditionalProperties>
When I used the Properties Xml node, I got a new error:
The OutputPath property is not set for project
'MyInstallerProject.csproj'. Please check to make sure that you
have specified a valid combination of Configuration and Platform for
this project. Configuration='Debug' Platform='x86'. This error may
also appear if some other project is trying to follow a
project-to-project reference to this project, this project has been
unloaded or is not included in the solution, and the referencing
project does not build using the same or an equivalent Configuration
or Platform.
After failing to resolve the issues with any of the above answers, I simply followed the instructions contained within the Microsoft.Bcl.Build.targets file (displayed after double clicking on the error in the build output window).
I unloaded my project (referencing Azure packages), encountering the error. Edited the project file and inserted the following...
<PropertyGroup>
<SkipValidatePackageReferences>true</SkipValidatePackageReferences>
</PropertyGroup>
...at the top of the project file before the first PropertyGroup.
I have a c++ project in VS2010 and a c# project that is to consume this c++ project output (it uses it for p/invoke). I was thinking that I could ensure that the c++ project was build before the c# project by editing the "Project dependencies..." in the solution but this does not seem to have any effect, the build on my buildserver does not respect this setting (I'm using TeamCity to bootstrap an MSBuild file that builds the entire solution file)
I think this used to work, has anything changed with VS2010? Or should I declare the dependency in another way?
SOLUTION: The trick was to hand-edit the csproj file outside VS2010 and add a section like this:
<ProjectReference Include="..\CobraLib\CobraLib.vcxproj">
<Project>{598506DA-91DA-4F25-948D-A14CB16ABEBA}</Project>
<Name>CobraLib</Name>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
That made the build server process my projects in the correct order. Only caveat is that VS2010 displays an error on the project reference ("not a .NET project") but otherwise things are working as I intended