I have a solution with two C++ (CLR) projects. One project references the other, so the Project Dependencies and Build Order correctly reflect that. Both projects target the same output folder. The dependent project has the dependency configured with Copy Local: false.
If I "Rebuild" the dependency by itself, it builds fine and its targets are in the output directory.
When I "Rebuild" the solution (or the dependent project), I get:
error LNK1181: cannot open input file '<outdir>\Dependency.lib'
Sure enough, the dependency outputs are gone from the output directory. If I look at the build log, the dependency seemed to have (re)built correctly, but then those outputs seem to have been deleted as soon as the dependent project build started. Why would that happen?
Additionally, when I "Clean" the solution, then immediately "Build" the solution, I don't get any errors.
Isn't "Rebuild" supposed to be, effectively, Clean + Build?
A rebuild in Visual Studio cleans and builds the projects one by one, so what probably ends up happening is
Project A is cleaned.
Project A is compiled.
Project B is cleaned, removing parts of the output from Project A due to the same output directory.
Project B fails building due to missing dependencies.
More discussion here.
The second project is deleting anything from its output directory when you perform a rebuild on it. Cleaning does not discriminate between files that are bonafide project output, and other files. Clean All followed by Build All doesn't cause it because there is no cleaning of the output folder between building of the projects. In short, Visual Studio doesn't support multiple projects outputting to the same folder. Output them to their default locations, and then let Visual Studio copy dependencies as it was intended/designed to do.
Related
The Visual Studio 2019 project, which was built via cmake displays
File Modification Detected
The project ABC has been modified outside the environment
Reload ... Ignore ...
message.
How can I prevent cmake from updating the VS config files, for the project or system wide?
In what section of the cmake build files this behavior is defined (so that I can rebuild the project without this feature)?
No, you cannot prevent this (afaik). Consider the scenario where you add a source file to a target in a CMakeLists.txt file. CMake needs to update the Visual Studio project files it generated which results in project file(s) being overwritten. CMake sets up the solution in a way to ensure such an update on a modification of the cmake files. Visual Studio reacts to the solution/project files being overwritten by displaying the dialog you mentioned.
In general you'll want to click "Reload" which should just update the projects according to the modification in the cmake sources. If for a command line build tool shows up though, you may want to select "Ignore" though, since sometimes the build output is deleted on a reload of projects/the solution and you'll probably want to check the error message.
If you're interested: Overriding the project files happens in the ZERO_CHECK target.
If the dialog is displayed on a build even if you did not modify the cmake files since the last build, you may want to check the console for a warning in the output of cmake though; this may indicate that there may be some issue in your cmake files...
I'm trying to publish a project on NuGet staging server. The project has two dependencies: Mono.Cecil and ILRepack.
When installing my project at project level:
Mono.Cecil dependency is installed automatically at project level. I can also find it in the target directory of the project.
ILRepack dependency is installed too, but at solution level. There is no mention of ILRepack.dll in the target directory.
Since my project requires both Mono.Cecil and ILRepack to be actually in the target directory, this is rather annoying. There is no “Copy Local” to check like for ordinary references.
How do I force NuGet dependencies to be at the scope of the project and to be copied to target directory during the build?
Found it. The problem was that the NuGet package metadata was referencing ILRepack, when the one I actually needed is ILRepack.Lib.
Since ILRepack package doesn't contain the assemblies to be used in a project, but rather an executable to be called directly, it was forced to be installed at the scope of the solution, and there are no actual references at project level. Makes sense.
My issue is "When I build a project on my build server, it does not get the correct version. But when I build it locally the project locally it does get the correct version"
How do I know this? ...On the build server when I open the file, the contents are not what they should be, as they are in TFS.
I am using Visual Studio 2013 and WIX 3.8. On my build servers I have wix 3.8.
I have a WIX installer (INSTALLER XYZ) which references project A.
Project A has a configuration.config file inside it. The configuration.config file is essential for the MSI to work. When I build the "installer XYZ" locally and install it everything works fine.
When I run a build (on the build server) it builds "installer XYZ" and produces a .msi file. When I install the .msi file I get an error. The install fails.
After investigating and I have found out that when I build on the build server, the "installer XYZ" which references Project A configuration.config file is using an older version of this file and not the latest version. I don't understand why this is happening.
If I use the .msi which was built locally, it installs fine but when I use the .msi which was built on the build server, it does not install.
Let me explain a few things that I have tried...
The msi's are exactly the same except for this configuration.config file. I have used the tools LessMsi and Orca to examine the .msi's.
When I build the project on the build server, I have checked the configuration.config file and it is different the one in Project A
I have got the latest from TFS before building. I have got specific and overwritten all the files from TFS before building.
I have expanded project A and right clicked on configuration.config file and selected properties. The property "COPY TO OUTPUT DIRECTORY" is set to COPY ALWAYS".
My WIX installer is harvesting the files correctly. I have recreated my .WXS file and referenced project A correctly using Source="$(var.Connectors.AgentService.TargetDir)"
On my build server I have deleted all workspaces.
I have deleted all work spaces that my build service account created.
My build definition "Clean Workspace" is set to "All"
I have restarted my computer and the build server
To conclude, I know what the issue is but I'm not sure what's causing it... Can anybody advise?
Update 22.05.2014
So I've investigated further,
I have another project in the same solution called Project.B
Project.B also has a configuration.config file.
What seems to be happening is that the configuration.config file from Project B is being built. I tested this by changing the contents of project.B configuration.config file and rebuilding it. However, my WIX installer references project A configuration.config file.
It seems that the build process is getting confused between the two projects in the same solution.
Does anybody know why this could be happening?
In TFS build, all files are copied into one bin folder. However, Visual Studio has "bin folder per project" structure.
This would explain why your configuration.config is overridden by projectB. They are all copied into same folder.
You can split the folder structure again, by adding this property to your build definition:
Notice the flag /p:GenerateProjectSpecificOutputFolder=true
I've been pouring over my set up for what feels like most of the day and I cannot figure out what I'm doing wrong.
I have 3 build configurations running on a single agent on my dev box. Checking out code from SVN.
I've got OctPack installed to create a couple of packages for deployment. In addition to this I've created a nuspec file to use in a NuGet Pack step. All of these bits work fine when testing.
The problem is that the nuspec file packages up some sql script files for deployment. Nothing fancy.
The problem is these sql files are disappearing from disk in the work folder. I get:
Cannot start build runner: Failed to find files to create packages matching: [src\database\SqlScriptsPackage.nuspec] under H:\TeamCity-Build\work\a1dbf81458fbab0a.
The entire database directory is empty despite all the contents being in SVN.
I've tried everything I can think of, including a forcing a clean checkout.
All the projects are using the same VCS Root setup to checkout "Automatically on server".
What could be ditching all these files?
Disable the [] Clean output directory checkbox on the NuGet Pack step.
I had this issue where I set the target directory for the Nuget pack step to be the same folder as the .csproj file I was building from.
With the tickbox ticked, it wiped the entire directory immediatly after checking it out.
I had a similar error when running on TeamCity:
Failed to find files to create packages matching: [myProject/myProject.nuspec]
under {C:\TeamCity\work\XXXXXXXXXX}
The key for us was that reading this message you could interpret it as it cannot find the files to go in the nuget package.
However, the issue was that it cannot find the .nuspec file.
So this then helped us look at the TeamCity working directory and what we were missing to get to the 'myProject' .nuspec path above.
Another thing to check is that you have the Octopack nuget package installed in your Visual Studio project. I forgot to do this with one of my projects and received the "Failed to find files to create packages matching" error. More information is available here:
http://help.octopusdeploy.com/discussions/questions/2304-teamcity-804-not-creating-nuget-packages
I am a newbie in the Visual Studio 2010 environment. I got a source base which was developed using Visual Studio 2008. I am trying to build it in VS 2010; but the build fails as the Linker says the error - LINK : fatal error LNK1181: cannot open input file X.lib'.
Here X is the name of the lib file created from the same project and X.dll is the output dll. In fact the X.lib is not present in the project. Without succesfully building the project, it won't come at all for the Dll to build succesfully. How can I resolve this "Deadlock" kind of situation?
Thanks in advance,
Shiju
I had this problem also. When converting a working VS2008 project to VS2010, the Link phase breaks in the VS2010 project with the same error. It is trying to link the .lib that the project is supposed to be building!
I found the source of my problem: The project has a custom build step that occurs at the end of the build, before the PostBuildEvent. This custom build step copies the .dll, .lib and .pdb from $(OutDir) to an external location.
The Outputs List for the custom build step is set to the full path to the copied .dll, .lib and .pdb, e.g.:
C:/a_new_location/myproject.dll;
C:/a_new_location/myproject.lib;
C:/a_new_location/myproject.pdb.
I found that whenever this Outputs List includes the .lib, that .lib gets added to list of files to link in the link phase. So with the above Outputs List, the link phase will have a file list of:
myprojectfile1.obj
myprojectfile2.obj
C:/a_new_location/myproject.lib
And that causes the link to fail:
LINK : fatal error LNK1181: cannot open input file 'C:\a_new_location\G4SrcCfgLib.lib'
It does not matter if the copy in the custom build step actually copies the file or not. All that matters is that the Outputs List includes the .lib. So, I resolved the problem by removing the .lib from the Outputs List, of course. The downside to this is that doing a Clean build will not clean C:/a_new_location/lib. But at least it builds.