Any suggestions? Code and artwork/assets are all in SVN, and we don't want to port it to GCC or another compiler before anyone suggests it!
Simplicity and minimising 3rd-party tools is preferred, since we don't have a build-server it'll probably still be run on a developer's PC but we don't want them just doing a build manually and packaging it up.
It's basically just a C++ solution with several projects, plus we have an Inno Setup installer to build.
Right now it's a 3-step process (or 4 if you include uploading the release to FTP):
Get from SVN
Build solution from VC++
Run Inno to create the packaged
installer
You can use MSVC pre, post & custom build steps to do this, they run programs through the windows command line. also see this: http://blogs.msdn.com/b/visualstudio/archive/2010/04/26/custom-build-steps-tools-and-events.aspx
If you can't do it with the VS build steps (see Necrolis' answer), then in the past I've used makefiles run with nmake, which is included with VS (you need to start a command prompt with the right environment settings for VS - there's a shortcut on the start menu.)
Nowadays I use FinalBuilder ( http://www.finalbuilder.com/home.aspx ) for all this sort of stuff, which is expensive and doesn't meet your 'not 3rd party' desire, but is an excellent tool. Once you get into it, you'll realise that there are probably far more steps you'd like to do than merely compiling/packaging - you probably want to be incrementing version numbers, moving files around, creating directories, etc. FB is good at that sort of stuff.
I am adding up to date answer for other users:
Currently there is 3rd party extension available which integrates Inno Setup into Visual Studio and allows you to build installers directly from IDE (or from command line using MSBuild).
It is possible to use pre, post & custom build steps, batch files, code signing, running programs through the windows command line etc.
Check Visual Studio Marketplace for more info about Visual & Installer: https://marketplace.visualstudio.com/items?itemName=unSignedsro.VisualInstaller
Related
If I'm in my WSL2 Ubuntu filesystem I can simply navigate to a javascript/nodejs folder and type code . to open that project folder and thanks to VS Code's Remote extensions, I'm essentially remoting into the Linux environment and ready to code.
Now Visual Studio 2022 has been released, I was wondering if it too supports the same level of cross-platform IDE capability as VS Code?
How, for instance, when in my WSL2 Ubuntu project in Windows Terminal, can I open my javascript/nodejs project in the Linux filesystem using VS2022, or is this not supported because VS Code is the only cross-platform IDE that can do this?
So its not really possible to do how your thinking. The problem here is that you your not understanding the difference between a "Code Editor", and an "Integrated Development Environment (IDE)", which is totally understandable, as the line that separates the two has become blurred in recent years, and also a topic of debate. There was a far more explicit distinction between the 2 10-15 years ago, however, Microsoft has done a good job at separating the two, where JetBrains will release a piece of software that can be used as an IDE, but is more often than not, used as an editor, but will still call it an IDE, even though its not an IDE in a pure sense.
How is all this related to your question?
When you open your Node.js project in VSCode via the code . command, you are opening it in an editor that implements Intelli-code, as well as a wealth of other tools, but essentially, the editor, and all the tools extract the names & file extensions of your documents, parse them (usually turning much of the info into an AST, where many extensions will make use of that info to offer the various tooling capabilities/features. The point is at the end of the day, the editor just parses all of your code, gives you info, and you make any changes as needed to your code. And again, this is what your doing with code .
With Visual Studio 2022, you can't open a project with it, unless its a project type the IDE supports, and enables the IDE, to embed its-self into your project. This includes things like built in environment, built in cache, built in build system, the files needed to bootstrap its-self. With an IDE, the IDE is part of the project.
So then why does Visual Stdio 2022 work with Node?
It works with node, to create Node.js applications within a windows environment, and it offers the ability to access different Windows SDK features via Node. These are things you could never do using server-side Linux builds with Node. When you build a Cpp application for windows, you package the entire thing in a .sin file, I haven't built a windows app in node, but I know that Node also uses the .sin file build system, which requires Visual Studio & Windows SDK to do, and parts of Visual Studio/Windows to be embedded into the project, for the project to be able to work in a Windows OS, and take advantage of MS Windows features.
Long story short, V.S. Code is the right tool for what your doing, why would Microsoft invest in two identical tools any way? If you ever want to build something for Windows, or for MS mobile device using Node, you will probably want to change your environment, to VS2022.
I am working with a setup project of Visual Studio 2015. I want to distribute the 2015 C++ library, vc_redist.x86.exe. But I don't want user to be aware of this pre-requisite, so the idea is that while he is running the .msi, the C++ library will be auto-installed.
I have been reading about the merge modules, but this cannot fix my problem because the setup.exe should be run. Please, could anybody tell me how to deal with this?
Many thanks!
You'll need to change (or create your own custom one) the standard bootstrapper that has documentation starting here:
https://msdn.microsoft.com/en-us/library/ms165429.aspx
The bootstrapper packages contain the detection and install logic for the redistributables. For example, the \Bootstrapper\Packages folder has VC redist folders, each with a product.xml and a package.xml about installing them as prerequisites. They have standard command lines such as:
Command PackageFile="vcredist_x64.exe" Arguments=' /q:a
and you can substitute that command with something like those listed here:
http://asawicki.info/news_1597_installing_visual_c_redistributable_package_from_command_line.html
that show the quiet options (as do standard Microsoft docs somewhere).
We're planning moving from Visual Studio 2005 to Visual Studio 2012 (Visual-C++-11).
(We would very much like to skip 2010 if we can help it, since the newer version is already there and offers a better C++ experience.)
But we've hit a little roadblock:
Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.
Developers mostly have switched to Windows7 by now, so moving the remaining Windows XP developer boxes shouldn't pose a problem.
Since VS2012 only runs on Win7 we are wondering whether we can leverage it's tools (C++ compiler, C#) and still do a full equivalent build on the W2k3 build server - after all, we don't really need a VS GUI there, just build C++ and C# projects from VS2012.
What are our options?
Will the SDK (7.1? 8?) compilers + msbuild command line get me anywhere?
In Project Property Pages, there an option "Platform Toolset" that allow you to choose compatibility of your project. So, you can work in VS2012, but built it with "VS2008 compiler"
Here is what we do:
Use CMake
CMake allows you to create build systems for your operating system. Thus we are able to use the same code within VS2005, VS2010 and Eclipse, XCode etc.
You could do something similar: Install VS2005 on your old machines and let CMake create the projects for you from the sources. On your newer machines you can use CMake to generate VS2012 Solutions (I don't know if they have 2012 support yet, because we don't use 2012 yet too).
A big pro here is: If you plan to migrate to any other IDE or even Linux you just can re-run CMake and get your source code within these environment easily compilable.
A big con: You have to start reading about CMake and create CMakeLists.txt for all your projects (might be a lot of work depending on the amount of projects, amount of source code files within each project, specific compiler options, linker options etc.)
Our build servers still run Windows 2003r2 (all inside dedicated
virtual machines), and due to messy tool support/issues, we're in no
position to upgrade the build servers to a newer OS.
Well. Not much came out of this question. We recently re-evaluated this issue, and I see two options (I haven't tried any yet):
Just do a full VS installation on a supported OS (Win7), zip up the whole VS+WinSDK directories (as well as the neccesary runtme DLLs that live somewhere under %WINDR%), and try if you can get that thing working on an XP based OS. Might work. Not a great idea if you ask me.
Split up the build process to distribute the build across several OS, so that we can work with tools that are only supported on one of them. -- This actually sounds more complicated than it'll be. We already run our build spread over several Jenkins jobs, so I should be able to get that to work. (And all build nodes are already VMs anyway, so adding more VMs isn't that much of an issue.)
I have an application that uses the ms vc++ runtime. How should I install it on the end-user's system if it is not present? I was thinking of bundling it with the installer... but how would I do that as far as what to include? Is there some silent installer? If so, where can it be found? I can't seem to find it in the Windows SDK.
There is an interesting post about deploying the runtime libraries on the Visual C++ blog. The post is about VC8 so I'm not sure all the recommendations apply to VC9.
Here are your options according to Microsoft:
Use an .msi installer including the .MSM files for the VC
libraries you're using. These MSM
files install the libraries globally.
They also keep a reference count so
that the libraries are removed when
the last application using them gets
uninstalled.
Use "app-local"
deployment i.e. copy the
libraries and manifest files in your
application directory. This is a simpler
solution if you don't use an .msi
installer. Your app should still use the
system version of the libraries if they are more
up-to-date than your own.
Link everything statically (and avoid crt usage across dll boundaries)
Another option Microsoft discourage you from using is running the Visual C++ redist installer from your own installer.
I'm not sure what their reasons are. It will take a few extra megabytes and will not be reference counted but it still works very well AFAICT. You can pass the /q option to vc_redist_x86.exe to perform an unattended install (no user interaction).
It has it's own installation program. I've seen it usually run as a prereq step of a larger installer.
One way or the other, you need to list it in your manifest. So you might just as well deliver it as via SxS in your application rather than try to deliver a global copy to the target machine. SxS is a big hard subject, sadly. Hopefully someone will supply an answer with more details and I'll delete this one.
i have developed application in visual c++ 6.0,i have do exe of that application,i have done by using icnt.exe(install creator),but when i run my application exe file on other system which does't have the vc++ software it's showing dll files are missing,how could than i downloaded the dll files again it is asking other dll's files.i want run my application without installing vc++ software in windows,how can i solve it,plz help me i'm touble.
How to make Realease build? by default its debug build
thanks for reply.
As a wild guess, you have deployed the Debug build, which depends on DLLs that are not allowed to be shipped.
If that is the case, have VC6 create a Release build and deploy that.
You can verify which DLLs are required by your application with the depends.exe utility that came with Visual Studio.
Edit: The easiest way to get a release build when ready is to use the Batch Build command from the Build menu. It will let you pick among all of the known build types in the project, and choose to either build them clean (recommended) or to just bring them up to date.
It is also possible to switch the GUI to default to the Release build instead of Debug. That is the right thing to do if you actually need to run the debugger on the Release build. Note that both builds include debug symbols. The differences have more to do with which runtime libraries are linked, and certain optimizations such as making the assert() macro have no effect.