I will be creating a series of projects set up to build COM objects. I attempting to create a property sheet (.vsprops file) which will set up the builds for each project. One of the things I am doing with the properties file is customizing the location and names of the files created by the MIDL compiler. Here's the code I use for this:
<Tool
Name="VCMIDLTool"
TypeLibraryName="$(InputName).tlb"
OutputDirectory="$(RPCDIR)"
HeaderFileName="$(InputName).h"
DLLDataFileName="$(InputName)_dlldata.c"
InterfaceIdentifierFileName="$(InputName)_i.c"
ProxyFileName="$(InputName)_p.c"
/>
RPCDIR is a macro defined before this section of the property file. This works great for compiling the code. When I build my project, these five files are created with the correct names in the location I specified in the RPCDIR macro. My problem is when I try to clean the build. The clean successfully deletes four of the files, but the DLL Data File does not get deleted. I'm especially confused that some are deleted and one is not - I would have thought that either they would all be deleted or none be deleted rather than a split like this.
Does anyone know how I can customize the clean build to correctly delete these files? Optimally any changes I need to make would be in the property sheet so that I can share it with other projects, but if that's not possible then I'd like to at least be able to do it in the project file. Thanks in advance for any help you can offer!
Not your problem, it is a bug in the build system. The dlldata.c file doesn't get deleted using a regular build either. There aren't enough diagnostics available in the msbuild .log files to see what target fumbles this. I'm guessing it has something to do with the <FilePatternsToDelete> item in the Microsoft.CppClean.targets file.
I recommend you report this problem at connect.microsoft.com
Related
I have several protobuf messages in a folder which I'd like to automatically convert into the respective header/cc files and then continue the compilation process inside of Visual Studio.
The best solution that I could comeup sofar was to define a Pre-Build Event through Propertise>Build Events>Pre-Build Event and specifying the following as the command:
$(SolutionDir)Dependencies\include\protobuf\bin\protoc.exe --proto_path=$(SolutionDir)Dependencies\include\messages\ --cpp_out=$(SolutionDir)Dependencies\include\messages\ message.proto message2.proto message3.proto
There are currently 2 issues concerning this solution :
I have to manually add each filename myself. How is it possible to make the filenames get picked automatically by VS2019? I tried %filename% macro, to no avail since it seems it returns the project file names only.
I also found out, these files are not generated each time I change the messages. even cleaning the projects, doesn't delete them, so I have to manually delete the generated files and try rebuilding the project again!
Other than resorting to a batchfile that can get called as a prebuild event, how can I achieve this inside Visual Studio without doing that?
I suggest you could refer to the following steps:
1,Modify the properties of the .proto file:Item Type:Custom Build Tool
2,Configure project properties: Properties -> Custom Build Tools -> General
command line:$(SolutionDir)Dependencies\include\protobuf\bin\protoc.exe --proto_path= .\proto %(Filename).proto --cpp_out=$(ProjectDir)protocpp
Description: protoc %(Filename).proto
Outputs: $(ProjectDir)protocpp%(Filename).pb.cc
Add Outputs to Item Type: c/c++ complier
And then you could try to build the .proto file.
Note: The newly added the .proto file also needs to select the operation of the Custom Build Tool
I want a run a build step that looks at a .h file, adds some code based on some external params, and hands the resulting file to the preprocessor.
I see the "Custom Build Step" in the project properties. It seems to need an output file. I just want to forward the results to the preprocessor.
It seems like the custom build step wants to do a 1-time process, not per-file or by file type.
The problem is that I don't know how to send my external executable the file currently being processed (eg, "HelloWorld.cpp"). $(InputName) and %(Filename) are blank and docs say it's deprecated. How do I send the filename to my external executable?
But even if I get that working, I don't want to set this per-file. I want all header files to go through this process.
Any ideas?
I've looked at:
https://msdn.microsoft.com/en-us/library/dd293663.aspx?f=255&MSPPError=-2147217396
https://msdn.microsoft.com/en-us/library/hefydhhy(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/ff770593(v=vs.140).aspx
working on a debug, x64 config on windows.
First of all, No, you cannot modify a file and pass along the results to the next stage (that I could see). I'd need some sort of Program Transformation System.
So I need an intermediate file. That file has to be added to the project, even if it gets overwritten by your code generator. I can associate c++ header files with a custom build tool, and they will all get called one-by-one in the stage of the build specified in the Custom Build Step. The custom build tool will modify the intermediate file(s), and all is well.
The VS 2015 name for the current file being processed is %(Filename). In older versions it has been $(ProjectName) and $(InputName).
I'm working in MFC (C++11)in VS2015 and I have a set of standalone GUIs that i'd like to use across multiple projects. I know this is possible by creating a .rc file that can be included in the main .rc file of each project based on this:
Using Multiple Resource Files
While conceptually I understand what it is describing, i can't find any example of creating the standalone .rc file and second resource file. I created a test resource header file that lives globally in my solution and tried to include it using Resource Includes, but it can't find it, even with the path. Can anyone point me to links or examples on how to set this up?
I have either .rci files, that are never used with the resource editor. They are used with #include freely.
Or I have special .rc files that contain standard symbols and messages, that are used over a larger set of projects.
I just simply add the second rc file to the project. This resource file is simply #include'ed into the main .rc file of the project.
To prevent errors in the project. This second .rc file is excluded from the build. In the solution explorer right click on the item. And set Exclude from Build to YES.
Take care about collisions of IDs.
Here is how I do it. If you drop the resource you would like to include on the resource folder in the solution explorer, it will show up as a separate and editable resource in your project
You will have to include the headers in your project that go along with them, of course. So watch out for collisions of your IDs. You may have to go to the new resource and use IDs that have been set aside by adjusting _APS_NEXT_XXX_VALUE. I've never used the 'Resources Includes..'. as described in TN035. I just checked and relative paths to bitmaps seems to work fine. Hope that helps.
I know two approaches of doing it. I will demonstrate it assuming you want it for the need of managing the fact your application supports several languages.
The first one is already described by user #xMRi, and depending on your configuration/platform you will include only the .rc in question. For example you have configurations:
en_GB
fr_FR
pt_PT
de_DE
and files
Project_en_GB.rc
Project_fr_FR.rc
Project_pt_PT.rc
Project_de_DE.rc
For getting this right, you will need to do Exclude from build on them all, except on the Configuration you have selected at the moment on the VS Toolbar combo. If you have fr_FR selected, do Exclude from build of all other .rc except Project_fr_FR.rc files and apply the same logic on every configuration.
The other is to have a VS project (vcproj) for each language, where each project contains the .rc file brlonging to it.
The projects
Project_en_GB
Project_fr_FR
Project_pt_PT
Project_de_DE
contain respectively
Project_en_GB.rc
Project_fr_FR.rc
Project_pt_PT.rc
Project_de_DE.rc
Here at work we use both (I never heard of .rci files before; we use the first with normal .rc files), depending on the project.
I have a very large VC++-Project which takes a long time to Rebuild after i edited a file. Maybe it's a central-class and so the following classes have to be rebuild, too. I'm using class-definitions and do include the header in the cpp-file, not .h-file in .h-file ;-)
Is there a way to find out which class/file is resposible? Are some useful tools to visualize the includes in a graph/dependencygraph? How do you get it?
Any file which directly or indirectly (through another include) #includes the file you changed will have to be rebuilt. Also if you have custom rules (say, the file you are editing is part of a custom rule that generates new source files), then any files changed by this rule and their dependencies will also have to be rebuilt.
MSDN Doc for visualizing the dependency graph:
http://msdn.microsoft.com/en-us/library/ff657798.aspx
ElectricAccelerator can help you answer this question by giving you an XML-annotated build log that includes information about which files are accessed during the compilation of each object, and the build time for each object. It has a Visual Studio plugin so it integrates right into your current environment.
Disclaimer: I'm the architect of ElectricAccelerator
I'm looking for a way to access all the Build properties defined while executing MSBuild. I have a configuration file. I want to modify the Properties in the configuration file and copy it to a new location. Is there a way to do it?
If you run the build with /verbosity:detailed or /verbosity:diagnostic you will get very detailed output of all the properties that was used during your build process. However I suspect you want to change a config type file after/before you copy the builded files to another location? In that case there is several mechanismes to do that, what we have found to work pretty good, is the MSBuildCommunity tasks that can be found here on code plex
If you would like to see some samples of this I would be glad to post them