Can anyone point me in the right direction how to configure Visual Studio 2005 with our C++ console project how we can include a 'File Version' in the details section of the file properties.
I've tried resource files without any luck. This is with a C++ project just for clarification, and big thank you for the guys you responded with C# suggestions.
Thanks in advance.
If you are talking about unmanaged c++, you need to add a version resource to the project.
right-click on the project, choose add - Resource.... Choose Version and press new.
There you can enter all info you need.
You have to have one VS_VERSION_INFO section in your resource (*.rc) file(s) that compile into your project.
In the Visual Studio 2005 Solution Explorer, open the context menu on your C++ project and choose Add, Resource.
Mark Version and click "New".
Fill in the fields as desired and save the file.
Build.
Now your project output has a FileInfo resource.
Please be aware that Windows Vista does not show all available version info in the Explorer context menu's "Details" tab.
For c++ projects I use StampVer and call it as a post build operation including check in/out of revision control for release builds.
Unless you have a good reason for your file version to be different than the version of the assembly inside, I think it is a better idea to provide the AssemblyVersion alone. If you do not specify an AssemblyFileVersion, it will automatically get the same value, so you can see your assembly's version directly in the file's properties.
The advantage is that you can use a wildcard and allow the version to be automatically incremented, so that every time you compile the library you get a different build and/or revision number. As far as I can tell, this trick does not work with AssemblyFileVersion, so you have to increment it by hand.
Of course, all this only applies if you're writing .NET code. Are you by any chance talking about a project using unmanaged code?
Related
I would like to perform an action upon opening a particular Visual Studio 15/17/19 solution.
I need to inform anyone who is about to work on the project that there are important notes (included in the project) that they should read first. Ideally it would be a pop up so as to be very obvious.
When googling I can only find solutions that involve Visual Studio extensions but I need something that does not rely on anyone else doing anything (e.g. installing the extension) - it needs to be something dependent only on the project itself.
I'm hoping for something that I can add in the .sln or .scproj file that VS will see when it loads the solution and take action, but anything that achieves the same purpose would be good.
I'd be grateful if someone is able to let me know how I can achieve this.
You've got an extension called Solution Open Pop Up supported on many versions of Visual Studio.
In the Overview tab there is a Features section where you can see a short example of how to use it. From the extension's website:
If a file called SolutionOpenPopUp.txt and/or ReadMe.txt exists in the root folder of the solution, the contents are shown in a pop-up when the solution is open.
My current preferred C++ environment is the free and largely excellent Microsoft Visual Studio 2005 Express edition. From time to time I have sent release .exe files to other people with pleasing results. However recently I made the disturbing discovery that the pleasing results were based on more luck that I would like. Attempting to run one of these programs on an old (2001 vintage, not scrupulously updated) XP box gave me nothing but a nasty "System cannot run x.exe" (or similar) message.
Some googling revealed that with this toolset, even specifying static linking results in a simple hello-world.exe actually relying on extra .dll files (msvcm80.dll etc.). An incredibly elaborate version scheming system (manifest files anyone?) then will not let the .exe run without exactly the right .dll versions. I don't want or need this stuff, I just want an old fashioned self contained .exe that does nothing but lowest common denominator Win32 operations and runs on any old win32 OS.
Does anyone know if its possible to do what I want to do with my existing toolset ?
Thank you.
For the C-runtime go to the project settings, choose C/C++ then 'Code Generation'. Change the 'runtime library' setting to 'multithreaded' instead of 'multithreaded dll'.
If you are using any other libraries you may need to tell the linker to ignore the dynamically linked CRT explicitly.
My experience in Visual Studio 2010 is that there are two changes needed so as to not need DLL's. From the project property page (right click on the project name in the Solution Explorer window):
Under Configuration Properties --> General, change the "Use of MFC" field to "Use MFC in a Static Library".
Under Configuration Properties --> C/C++ --> Code Generation, change the "Runtime Library" field to "Multi-Threaded (/MT)"
Not sure why both were needed. I used this to remove a dependency on glut32.dll.
Added later: When making these changes to the configurations, you should make them to "All Configurations" --- you can select this at the top of the Properties window. If you make the change to just the Debug configuration, it won't apply to the Release configuration, and vice-versa.
I've had this same dependency problem and I also know that you can include the VS 8.0 DLLs (release only! not debug!---and your program has to be release, too) in a folder of the appropriate name, in the parent folder with your .exe:
How to: Deploy using XCopy (MSDN)
Also note that things are guaranteed to go awry if you need to have C++ and C code in the same statically linked .exe because you will get linker conflicts that can only be resolved by ignoring the correct libXXX.lib and then linking dynamically (DLLs).
Lastly, with a different toolset (VC++ 6.0) things "just work", since Windows 2000 and above have the correct DLLs installed.
In regards Jared's response, having Windows 2000 or better will not necessarily fix the issue at hand. Rob's response does work, however it is possible that this fix introduces security issues, as Windows updates will not be able to patch applications built as such.
In another post, Nick Guerrera suggests packaging the Visual C++ Runtime Redistributable with your applications, which installs quickly, and is independent of Visual Studio.
Information about what I want to do:
-read in a few integer variables from a text file that will be located on a dropbox public folder.
-the variables will be used to trigger some if statements thus controlling my application remotely if I need to have it do something ( I would just save the variable I need to that text file and my program with would read from it every 5 seconds would see it and perform the required actions).
-this is a console application which is being built and compiled in visual studio 2010 on windows 7. The software will also be running on a win7 computer.
I need help with:
I already have read on using a library called libcurl. The problem is that I do not know how to link this library with my project in vs2010. Detailed instructions on how to do this on vs 2010 would be very helpful.
OR
if you can think of a better and easier way to accomplish what I need done, offer some advice and direction
It sounds like you're a novice, is that correct? If not then apologies for stating the obvious.
To use your compiled DLL in your application you need to 'add a reference' to it. You can do this by adding what is called a binary reference, where you simply tell visual studio where to find the dll. Or you can add a project reference if the project which is producing the dll is within the same solution. The best approach is to use something called nuget. It's a visual studio extension which automates the adding of binary references available from a public repository.
I have just done a search for libcurl on nuget.org and drew a blank. As I am unfamiliar with this library you may have better luck finding a nuget package as you will be a le to search using better terms that I did (curl and libcurl)
Whatever approach you take, just right-click on the project in which you want to use libcurl within the solution explorer and you should find an add reference option in the menu.
I got a huge C++ third-party project with set of project in one solution. So build time is rather long and Browse Information generation takes a lot too. So what is the purpose of Browse Information? What functionality will be lost if i disable Browse information generation?
Visual Studio 6 required browse information to do the things that Doug T. mentioned.
Newer versions of visual studio can use the browse information file, but by default use a newer Intellisense database. For those versions, there is basically an Intellisense daemon that builds the database in the background instead of being directly embedded in the build process. It really helps to have more than one processor or core when using Intellisense. Otherwise it can really bog down your system.
From here
Select Generate Browse Info under the
C/C++ project settings tab, for any
source-files that you want to be
included. This is very useful for
searching for function definitions and
declarations - just right-click a
function / variable and select "Goto
Definition Of..." and the IDE will
take you straight there.
You will lose some ability to easily navigate your code. This may matter a lot in a very large code base. I know that without it and tools like Visual Assist X, I would be lost. Still, Visual Studio has a very efficient find-in-files operation that cannot be completely replaced with browsing tools.
My current preferred C++ environment is the free and largely excellent Microsoft Visual Studio 2005 Express edition. From time to time I have sent release .exe files to other people with pleasing results. However recently I made the disturbing discovery that the pleasing results were based on more luck that I would like. Attempting to run one of these programs on an old (2001 vintage, not scrupulously updated) XP box gave me nothing but a nasty "System cannot run x.exe" (or similar) message.
Some googling revealed that with this toolset, even specifying static linking results in a simple hello-world.exe actually relying on extra .dll files (msvcm80.dll etc.). An incredibly elaborate version scheming system (manifest files anyone?) then will not let the .exe run without exactly the right .dll versions. I don't want or need this stuff, I just want an old fashioned self contained .exe that does nothing but lowest common denominator Win32 operations and runs on any old win32 OS.
Does anyone know if its possible to do what I want to do with my existing toolset ?
Thank you.
For the C-runtime go to the project settings, choose C/C++ then 'Code Generation'. Change the 'runtime library' setting to 'multithreaded' instead of 'multithreaded dll'.
If you are using any other libraries you may need to tell the linker to ignore the dynamically linked CRT explicitly.
My experience in Visual Studio 2010 is that there are two changes needed so as to not need DLL's. From the project property page (right click on the project name in the Solution Explorer window):
Under Configuration Properties --> General, change the "Use of MFC" field to "Use MFC in a Static Library".
Under Configuration Properties --> C/C++ --> Code Generation, change the "Runtime Library" field to "Multi-Threaded (/MT)"
Not sure why both were needed. I used this to remove a dependency on glut32.dll.
Added later: When making these changes to the configurations, you should make them to "All Configurations" --- you can select this at the top of the Properties window. If you make the change to just the Debug configuration, it won't apply to the Release configuration, and vice-versa.
I've had this same dependency problem and I also know that you can include the VS 8.0 DLLs (release only! not debug!---and your program has to be release, too) in a folder of the appropriate name, in the parent folder with your .exe:
How to: Deploy using XCopy (MSDN)
Also note that things are guaranteed to go awry if you need to have C++ and C code in the same statically linked .exe because you will get linker conflicts that can only be resolved by ignoring the correct libXXX.lib and then linking dynamically (DLLs).
Lastly, with a different toolset (VC++ 6.0) things "just work", since Windows 2000 and above have the correct DLLs installed.
In regards Jared's response, having Windows 2000 or better will not necessarily fix the issue at hand. Rob's response does work, however it is possible that this fix introduces security issues, as Windows updates will not be able to patch applications built as such.
In another post, Nick Guerrera suggests packaging the Visual C++ Runtime Redistributable with your applications, which installs quickly, and is independent of Visual Studio.