I'm using CMake into build rules in visual studio to preprocess my files before submitting them to the compiler but my customers don't like it.
Is there any CMake alternative or method to preprocess my files and having them integrated into visual studio?
As I understand the question you are using CMake to generate files consumed by a VS project that you created by hand. For whatever reason your customers of your VS project don't like CMake. Presumably you have wired this up by creating custom build steps that invoke CMake to generate the files in your project, either as Build Events on the project, or as custom build steps on various files in the project, such as the inputs to the scripts.
VS lets you run any arbitrary set of commands as part of a Build Event or a Custom Build Step. So you could replace CMake with a suitable script or custom executable written by yourself. It is hard to be specific without knowing exactly what about CMake isn't appealing to your customers.
You can use JavaScript through Windows Script Host to create fairly complex scripts that process custom build steps. They can take command-line arguments, access the file system, etc. For some reason WSH JavaScript is a big secret among most developers and they think that all they have available to them in Windows out-of-the-box are DOS batch files and power shell scripts. JavaScript has been shipping for over 10 years as part of the OS and you can debug the scripts in Visual Studio's script debugger, which is very nice.
Related
I have a dot-net project build with VISUAL STUDIO 2015 4.6.1 framework and I have two independent program folders in the source code which has some build errors. There are no references to these programs from the main program.
When I push the whole source code onto VSTS I get build errors. So now I need a way to exclude those two folders from the manual build for now but may need them later after they are debugged so I don't want to delete them from VSTS too.
Can someone suggest?
Use an MS Build project file. Create an MSBuild project file from scratch
And the at the build solution step in VSTS, select or type the project file path instead of the solution file.
You will have to remove it down the road though. The maintenance tasks tend to be hard and counter-intuitive whenever the code base grows quickly. Visual Studio will not warn you if you have build errors (like obsolete path) in the MS Build project file.
I build my app either as x86 or x64. This app uses external DLL.
I have x64 system (Windows 10) with the same DLL library installed for both platforms - x86 and x64. They are placed in same folders inside appropriate Program Files directory. I can manually set path to either one in environment variable PATH and it woks. But it is a little incovinient to rewrite PATH and reset computer when I switch platform and want to test the other one. Is there any solution, how system automatically loads correct DLL from correct Program Files dir?
I have found solution for running apps from Visual Studio: How do I set the path to a DLL file in Visual Studio?
It is working as epxected. If I run app outise Visual Studio, I set PATH variable by myself and is also working.
Copy the DLL in the build location next to the executable, for Visual Studio this is typically \Debug or \Release in a architecture dependent sub directory (i.e. x86 or x64). Just make sure the target / output locations are set correctly in the project settings.
You have to copy only once, or more correctly: each time after you 'clean' the solution. To make this easier, many people use a dll-copy script (use batch, ruby or python) and have it run automatically before building or after cleaning. You can execute the script in a pre-build step or post-build step that can be configured in your Visual Studio solution or project settings.
There is also a more robust way to handle build artifacts and peculiarities: I highly recommend the use of CMake to keep the build matrix organized. It is provides a general cross-platform approach to script pre-build and post-build actions such as tracking dependencies, copying files, packaging installers, deployment, version verification, versioning, etc.. it comes with an easy scripting language so you can build macro's and functions to do your copying. It can be a bit of a learning curve to get it right, but once it's there, it provides a robust dependable way to build out your project build pipeline.
I have a Visual C++ solution with multiple projects. One of the projects (let's name it Project 1) depends on both x86 and x64 versions of another Project 2. It means that when doing a rebuild of Project 1, no matter which architecture is selected I want both x86 and x64 versions of Project 2 to be compiled, prior to Project 1.
Standard Project Dependency feature doesn't allow to specify dependency on multiple architectures. Is there any way to accomplish this task?
Visual C++ has a command line compiler.
You can execute it on the project you need built, or split your code into multiple slns and tell the command line to build the slns.
This dependency can be set up as a custom build step, or you could go and write a makefile that describes your project dependencies and replace your sln build with that.
You can use a Custom Build Step or Custom Build Event to call msbuild twice, once for each architecture. This is how Visual Studio builds projects, so you are effectively recursively calling the build system.
Here's more detailed information:
Understanding Custom Build Steps and Build Events
https://msdn.microsoft.com/en-us/library/e85wte0k.aspx
I am new to Visual Studio, and I am trying to figure out the best way to organize my projects.
I am writing an application using the sfml library, and I have various resources (images/sounds) that I am using. I dropped these into the project folder, and everything works fine when I launch my application from Visual Studio.
I am wondering though, how does this translate to when a program is deployed? If I go into my solution's debug folder, and try launching the exe, it is unable to locate any of the resource files. Am I suppose to tell Visual Studio to copy files to an appropriate directory, and if so how?
Thanks for any advice or links.
For slightly more complicated "deployment" scenario, you can use post-build scripts to copy the correct files into the output directory and even package it into a zip file, for example.
If you find yourself writing more than one page of batch you may want to consider the options below, because batch is a PITA to debug.
Recent MSVS project files are actually MSBuild files (just open the .vcxproj file in Notepad or Vim). For instance you can use the Copy task, invoke arbitrary programs using the Exec task, etc. It can be a bit more sophisticated than the batch script in post-build scripts. MSBuild 4 can use Property Functions making it quite expressive. Useful reference if you do this
For a "full blown" project, you'll want to roll a dedicated build system using a dedicated MSBuild file, NAnt or even higher level wrappers like Rake.
As a less popular alternative, in a previous project I built a small dedicated "builder" .exe project in the solution and have other projects depend on it. Then in the post-build scripts of the other projects I just invoke the builder projects with arguments to make it perform certain tasks. The advantage is that you can write C# (or F# or VB.NET) and not have to fight the build system (as much) and I think it works quite well for small-mid sized projects.
for my project, I direct everything into one directory.
Go to ur project configuration, change General->Output directory, General->intermediate directory, and Debugging->Working directory to one directory. The reason you cannot locate the resource files is because the debug directory is not the same as the output directory.
I'm a fairly experienced C# dev, but have very little C++ knowledge. I have set my self a project to get a custom Firefox build running, and be able to control it from C# code.
I have got so far as getting and building the Firefox source, and creating a Visual Studio solution for the exe. This means I can now run via F5 in Visual studio. If I open a source file, I can set break points and have them hit.
What I'm not sure how to do, is load the entire source, as if I were working with a C# .NET solution. As I understand it, there are no project files with the Firefox source, as it is not windows specific source. I have followed an online example that suggests creating using 'project from existing code' option in VS, which resulted in VS grinding to a halt as there were so many files.
What are the steps to getting the code into an environment (preferably Visual Studio) that makes it simple(ish) to edit, debug and navigate the source code.
Note: Instructions I have been working through so far are here: https://cs.senecac.on.ca/~david.humphrey/writing/debugging-firefox.html
From you question, I beleive you are almost there. You have a working build ? That means you have :
A Solution File (*.sln)
A Project file (*.vcxproj or *.vcproj depending on yoru visual studio version)
With that in hand, what works best for me is this layout (adapted to your needs) :
Starting from a root folder of you liking, say MyProject
Create a new Empty solution there
Move the folder with your working build in a subdirectory, like MyProject\MyCustomFirefox
In Visual Studio "Add an existing project" and find your vcxproj file
In the same solution, create a C# project like you always do, in a directory at the same level as your FF build, like MyProject\MyFirefoxController
In short the solution file is pretty much alone in the root directory, and each project is in its own directory.
You will also need to adjust build options so that the output files (a DLL or an EXE) is seen by your C# project. While your are at it, make the C# project dependent on your Firefox build : it will instruct the msbuild to rebuild one if you change the other.
This will not work with the Express edition, I beleive. They are single language.
If you have a command line build path, which is creating a VS-debuggable executable, you could try adding all the source files to the project, but marking them 'exclude from build'. Then add a 'post-build step' to call the command line tools.
You may have to do a little more tweaking in the project properties to get the command line output recognized as the output to debug, but theoretically this could work.