I have a solution that has 6 projects, some of which are in separate DevOps projects. I am attempting to setup a build pipeline in Azure DevOps and my repository is already located there. Regardless of location, I continue to get errors that the csproj file cannot be found for any of the projects. The build cannot continue without the csproj files (obviously).
I have tried to move the .SLN file to the root folder, inside the specific project file and still get this error. I have also looked at the relative paths in the .SLN and attempted to manually modify them without any change.
Additionally, I used the vanilla configuration for the build pipeline before attempting to change path locations etc.
Here is the structure of source control:
Source structure
The 6 projects highlighted yellow are included in this solution.
Here is the output errors from the build in DevOps:
Output errors
I also tried adding the locations explicitly without any luck. By default, the location path was just $/PermitInspector/PermitInspector which is the location of the .SLN file. (Which is where I started with the attempt to automate builds).
Any suggestions would be helpful and I would be happy to share additional information or screen grabs that might be useful, but this is all I can come up with so far.
I was able to resolve the path issues by applying path filters under the build configuration in DevOps. There is a single work space and 3 of the projects are located in a root folder within the work space and the other 3 projects were in a separate root folder. The main issue appeared to be that the solution file is located inside the second root folder so I had to explicitly define the path to the other project files. By default, the only mapped work space was to the location of the SLN file. Now if I can just get NuGet restore working for the sub-projects! Thanks again,
Correct mapping that fixed the issue
Related
I'm currently writing AddOns for ArchiCAD.
Since .sln projects work with absolute paths, we wanted to try to have the same folder structure on every PC so we can share our projects with each other.
Example: Project for Room Numbering AddOn
I created a project under C:\workspace\ArchiCAD\AddOns\RoomNumbering
and the total path for every file is now C:\workspace\ArchiCAD\AddOns\RoomNumbering\...
and now everyone should be able to copy the folder structure and place the complete project folder in it and work with it.
I did this and tried to build the project on a different Computer.
When I open in vsc it finds all the files and external dependencies, but when I want to built the Project it hits me with an error:
FATAL ERROR LNK1811: cannot open input file "C:\workspace\ArchiCAD\AddOns\RoomNumbering\Build\ResourceObjects\RoomNumbering.res"
But this is a file that is supposed to be created during the built.
This is how it looks on my own Computer pre and after built.
The folder in question pre built:
The folder in question after built:
On my own Computer it creates the .res file, on other computers it does nothing (no new files get created after building).
I tried to build the Project first and then share it, so the .res file already exists. While this works, this isn't the desired way, since it still throws errors.
If it is relevant:
The projects get created by downloading the ArchiCAD AddOn Template (https://github.com/GRAPHISOFT/archicad-addon-cmake) and built it with CMake.
Does anyone know why vsc behaves that way or what I am doing wrong?
Thanks for any help and Kind Regards
Dayiz
I have been following some tutorials for c++ game programing. I am kind of new to c++ and I'm using Microsoft Visual C++ 2010 Express IDE. I'm working on creating a game, and when I run the program through the IDE, it shows the grass sprites as expected. But when I run the .exe file from the Release folder, it shows weird images. and when I run the .exe file from the debug folder I get a grey screen. Can anybody tell me why this is happening?
I hazard to guess that your sprite images are kept as data files in your project folder. With that I offer the following premise:
The default run-location from the Visual Studio IDE is the project folder of the project which you're executing. That is, normally it executes from the directory where your .vcproj or .vcprojx file is kept (and that is often one folder below your solution directory folder, where your .sln file is kept).
If your project runs correctly from the IDE, but fails to run directly from the release folder, it is highly likely you are relying on project data files (images in your case) that are kept along side your source files in the project folder. When run from the Release folder, those files are no longer visible because your the Release folder is your working directory; not the project folder.
There are a number of ways to solve this problem, each with its own merits. A few options are:
Post Build Step
Make a post-build step for your project that copies your data files to the $(TargetDir) location with your project. These files will then be visible in the same directory as your executable.
Benefit: Its easy.
Drawback: It will always run if you click "build solution" even if the data files are "up-to-date."
Custom Build Targets
Add your data files to the project and write a Custom Build script that performs the same copy, but also establishes an output dependency file(s).
Benefit: Almost as easy as #1, but a little more tedious.
Drawback: You may have a lot of data files and each will require its own custom build step. (Note: you can multi-select all the data files in your project, and if you're creative with the built-in macros you can have them all use the "same" build rules and commands).
Embedded Resources
Add the data files as custom resources to your executable.
Benefit: Your project no longer requires data files side-by-side with the executable since they are embedded in the resource table of your EXE module.
Drawback: Custom code is required to dynamically load the custom resources from your executable's resource table rather than off-disk. It isn't difficult at all to do, but is additional work.
There are other options as well, but I hope this gives you some ideas to start with.
I use VS2008 and try to answer your question. Right click on the project and select properties on the bottom of popup, then go to Debugging under Configuration properties. You can see command you run and arguments you pass in IDE. I guess you miss some parameters.
I have used visual studio 2010 express for a while and have played with some extensive projects for quite some time. Since i'm nearing 50-60 files and thousands of lines of code, i've decided to do some source control for everything so that the project is more easily updated and accessible between all my devices, while also being back up.
I have used git before and am comfortable with it, but now when i made the commit and pushed it to a remote repository on bitbucket.org, i found that the .vcxproj files, while still retaining their correct file structure, also retained the include and lib directories for the device it was pushed from, meaning that when pulled down to another computer, those include/lib directories would be looking in the wrong directories, meaning i have to revise all of them every time i pull/push.
My question, Is there anyway i can push files to the repository such that the solution keeps the folder setup, but not the include and lib directory settings?
Edit:
After some research, i went looking into these so called property sheets in visual studio which are files that can be added to your project. The settings you set their take precedence over the settings of the project, but then the snag there is, if you add the individual property file to the project and then push the the .sln file, and the various .vcxproj files without that .props file, and then someone else clones from the repository, it won't open because it apparently requires that props file.
What i would like along these lines is a default .props file in the remote repository that, when cloned over, is no longer tracked, and then that user can just edit it for themselves. I don't know enough about git thought to make this happen. Does anybody have an idea?
I'm not sure what your problem is exactly, but here's my understanding:
Your project files contain absolute paths (e.g. "C:\myproj\include"). Replace these with relative paths (e.g. ".\include"). The "$(SolutionDir)" variable helps: if your solution file is C:\myproj\myproj.sln, then "$(SolutionDir)include" is the same as "C:\myproj\include". You can change the include and library directories in Project Properties > Configuration Properties > C/C++ and Linker, respectively.
Your project requires third party libaries - such as boost - and these are outside your project, say C:\boost. Unfortunately Windows/VS doesn't have a standard location for third party libraries, so you can either:
Include the library in your project. This is perfectly fine for small libraries, but it's not something you'd want to do with something like boost, which is both big and tends to be used widely.
Mandate that all devices set up these libraries in the same location, e.g. C:\sdk
Use an environment variable, like $(SDK_DIR) in the project, and all devices must set this environment variable.
Let me know if this helps.
What you're after are git's smudge and clean filters. You'll have to write a script for the cleaning, but sed'll probably do the job just fine, you won't need real xml parsing.
I'm setting up an TFS 2010 Build server.
But I currently have the problem that projects with an "custom build tool" won't build because of "no access".
The projects are C++.
The custom build tool is "Pro*C". Basically, you have an *.pc file, and it generates an *.cpp file.
But on the build server, the directory/files are readonly. So it will crash on "no access".
I have tried to remove the *.cpp file from TFS. So that the generated file does not exists. But apparently the folder is also readonly and won't allow to create a new file.
Does anyone has a workaround for this?
I would suggest one of these options:
Don't put the .cpp files in source control if they are generated by the build process
Change the settings for Pro*C to write its output files to a writable intermediate folder
Add a build step that copies the problem files to an intermediate location for processing
Add a build step that forces the file access on those files to be readable for processing
If you only need to build those files occasionally, then build them manually with Pro*C on your developer machine and check in the results, so you don't waste time unnecessarily rebuilding unchanging files with every desktop or build-server build.
There is a project called MSBuild Community Tasks, which can be downloaded from http://msbuildtasks.tigris.org/. I used it for my own for an automated tfs-build.
It provides you with several extensions for your msbuild-project. One of this is the so called Attrib task, which gives you the opportunity to change file (and probably folder) attributes out of you project. It's not listed in the table on the website, but its documented in their documentation. As a sample from their documentation, you can add the following line to a target of your choice:
<Attrib Files="Test\version.txt" ReadOnly="true" Hidden="true" System="true"/>
I think this will also work for an item-group as follows
<Attrib Files="#(AllYourFiles)" ReadOnly="true" Hidden="true" System="true"/>
If you want to use it, don't forget to install it on the build server. ;)
Our company might be moving from CVS to Subversion soon. This has brought about an issue for us, which I am trying to solve.
For CVS and Eclipse, we were able to use team project set files to gather various modules and check them out together (http://vpms.de.csc.com/projectset/). This made it very easy to manage projects, since there was no need to remember each module in the project.
However, project sets do not support SVN. I know there is an 'externals' property for SVN that does approximately (or possible exactly) the same thing. I tried this. Now, for the problem:
When I use the externals property and checkout 2 modules in eclipse, their C/C++ project properties are lost, and so I cannot right click on them to say "build project" or "clean project". They appear to Eclipse to be folders with files in them.
Is there something I am missing here?
EDIT
When I check out each module separately, they check out as projects, so they do have the individual .project/.cproject/settings stuff
You forgot to place Eclipse project metadata into your source control system. Make sure all files starting with '.' in project root make it in along with the entire contents of the .settings directory.
Subversion externals simply allows you to take files from one part of the repository and bring them in under a folder in your local checkout. At my last company, we had a java source directory that called "commonSrc" that was an SVN External for another project's main "src" directory, but in the project it was brought into, it simply acted as another folder (as you are experiencing).
I never really liked that method and wouldn't recommend it unless you have only one/two modules.
In order to do what you are trying to do with SVN, you might have to checkout each project separately, and use "Module Dependencies" in the project's properties to create the proper dependencies in Eclipse. You might be able to commit these project files so that the next person doesn't have to re-link them.
In case anyone needs this, here's what I found:
http://vpms.de.csc.com/projectset/
&
http://www.polarion.org/index.php?page=download&project=subversive
OR
http://www.giniality.com/old/update/projectset/
for Subversion + Project Set integration.
There is no need to break your project set. Once you have the integration plugins installed in Eclipse, all you need to do is change the source from the CVS server to SVN.