ll the solutions , how can i get the path of that text file in postbuild event using macros, as i have different folder structure for different solutions ,So can't fetch the text file value by using $(SolutionDir) macro
Related
I have a standard (?) project (vcxproj) with multiple .asm files in Visual Studio 2019 Community 16.6.
In Configuration properties->MASM I have not set anything
Still the .lst file is created for the project. So, there must be some "hidden" defaults somewhere. However, even if I set them explicitly - there is no setting as to for which .asm file the listing file should be created.
I could not find anything as to the default implicit behavior / explicit behavior of choice of one .asm file over another. Logically, it would be the file containing the entry point in x86-32bit "end main", but that's not the case. Also, is there a way to generate .lst next to the .obj file for all .asm files in a given project.
right for me:
Open Project ,
Create a file (*).asm AND write code
Go to Property of Project: ( note platform for correct in first line - for me: WIN32 )
Go to Microsoft Macro Assembler - Listing file - set Yes(/Sg) Enable Assembly Generated Code Listing
and set $(ProjectName).lst in Assembled Code Listing File
Go to property of file (*).asm do the same thing as above...
Thanks for watch
The default value of working directory in visual studio property sheet is $(ProjectDir). If we have some dependencies (e.g., config files or libs & dlls), we have to put them in the working directory.
Since the default $(ProjectDir) is different from the output directory (namely $(TargetDir), folder where the EXE file resides), we have to copy the dependencies to the output directory if we run the EXE file by double clicking it.
So I'd like to change my working directory to $(TargetDir), in case I have to copy my dependencies twice. The question is: Why is the default working directory set to $(ProjectDir) but not $(TargetDir)? Is there any good reason for visual studio to do so?
I have a number of projects which are joined into a solution. Every project has it's own directory structure, and csproj files are located on diferrent level of folder structure.
Every csproj has OutputPath property specified. OutputPath - is a relative path and it varies from project to project in such a way so all projects have the same output dir.
It is work OK if I build a separate project. But everything changes if I try to build solution file. In this case every project output folder differs (depends on a number of '..\' in that project's OutputPath).
I do know, that before some moment all was working fine. Nobody changed build.cmd neither any sln or csproj files. But now I have situation described above.
So my question is - what affects how relative path is evaluated? I mean how can I force relative OutputPath to be evaluated starting from folder where csproj file of that particular project is located. Not from folder where .sln file is.
Let's assume I have following directory structure:
dir1
a.sln
dir2
a.csproj
dir21
dir3
b.csproj
a.csproj has output path set to '../../_bin' which is just above dir1 if counted from a.csproj folder
b.csproj has output path set to '../../../_bin' which is same - just about dir1 if counted from b.csproj
a.sln contains both - a.csproj and b.csproj.
When I run msbuild I get a project build to 'dir1/../../_bin' and b project to 'dir1/../../../_bin' - both relative paths of projects files are counted from solution file location, not project files.
Well, I was able to find out what was causing this. That was custom .targets file, which was inferring SolutionDir property at the start of any msbuild.
I did find out that by using MSBuild Explorer. The tool proved to be very useful in my case - I was not aware of third party .target files on my system.
From Msbuild Import Element description
Relative paths in imported projects are interpreted relative to the
directory of the importing project. Therefore, if a project file is
imported into several project files in different locations, the
relative paths in the imported project file will be interpreted
differently for each imported project.
All MSBuild reserved properties that relate to the project file, for example, MSBuildProjectDirectory
and MSBuildProjectFile, that are referenced in an imported project are
assigned values based on the importing project file.
If you add more details or few samples to your question - it will be easier to understand exact problem.
Edit:
Okay, lets try to pinpoint that mystery. First of all - OutputPath could be affected by Environment variables.
2nd - during build sln file transformed into msbuild project file format and stored in temp file. You can get that temporary file if you execute in cmd "set msbuildemitsolution=1" and then trigger build via command line. There you can check that file and see how your individual projects called. But I suppose you will see multiple .csproj /> entries. And global msbuild properties inherited by that calls.
So I suspect if everything was fine before some point and no changes were made - you are missing OutputPath environment variable or some other variable that contributed to construction of OutputPath.
BTW - I think if you want to fix your issue with forcing relative dir - you also can use $(MSBuildProjectDirectory). This is one of msbuild reserved properties (from here), but this will require yo adjust your OutputPath in each csproj file. What i, personally, prefer to avoid, because it could affect some other targets and introduce subtle issues.
Since I write a command line program to check cpp files, and it need lib path and include path of those cpp files.
How can I get the include and lib path info from visual studio project? Our project uses property sheets to make up those information.
It is made up from 3 distinct sources:
Tools + Options, Projects and Solutions, VC++ Directories. In turn built up from several registry keys
the settings in your .vsprops project property sheets
the settings in your .vcproj project
The first part is the hardest, you can get it by running vc\vsvarsall.bat. The .vsprops and .vcproj files are XML, easy to parse.
If you just want to find out what the command line should look like then you can get it from the buildlog.htm file, produced when building from the IDE. Or you could use vcbuild.exe on the command line to build your project from the .vcproj file. Or you could build using devenv.exe /build.
Check out the Visual Studio project files - they're typically only XML files, so you should be able to extract out whatever you need from those, really. Just a matter of understanding and parsing your XML contents in the project file, really.
I have a standard c# application that acts as a GUI front end for a an "R" statistics engine. "R" consists of approx 600 files in approx 50 different folders and can be "installed" on a machine through xcopy deployment.
I would like to package up both the R engine and my c# gui into one setup.exe so that the user doesn't need to go and install R first and then my c# application seperately.
I know that I can produce a setup project and then add in the R files one by one but adding all 600 files will be very tedious!
Is there an easier way of doing what I want? Can I add the single R folder and automatically add the subfolders and files to save me adding them in one by one? Or maybe do an unzip procedure in my setup project which will unzip the R engine in one go?
You can simply drag/drop the folder in Windows Explorer into the File System view of your Installer vdproj. All the files and folders in the hierarchy will be added to your setup project.
Tip: If the folders are in SVN or similar source control, delete all the hidden folders before you do this! If you have PowerShell, check out
get-childitem . -include _svn -force -recurse | foreach ($_) {remove-item -recurse -force $_.fullname}
Or you can always use Windows Search to find all hidden directories in the hierarchy and delete them from the Results Window.
I couldn't work out the project file so what I did in the end was to zip up all the files I wanted to deploy, add the zip file to the application and create a custom Installer class to unzip them (using CSharp ziplib)
I think Badjer is most of the way there.
If your 600 files are part of a project and the "Build action" for each of these is set as content you can add all of these by simply:
Going to the setup project
Selecting Add > Project Output
Selecting the project the files belong to from the drop down
Selecting the "Content Files" option from the list below
Clicking OK.
You can check the files will be added to the appropriate place by going to View > File System on the setup project and checking that the content files output is being added to the correct folder.
The files will be added to the install directory in the same hierarchy as they are specified in the project they belong to.
Have a look at the project file. I believe is text based. You might be able to insert the file paths directly there with some copy-paste-replace.
One thing you could try is adding the R files as content in the C# project - then the setup project can just copy them over for you (make sure you configure the setup file to copy content files from your project, not just the primary output).
You can either add the R folders into the project manually, or set up a script to modify the .csproj file (it's just an XML file) - content items are represented by these nodes:
<Content Include="myfile" />