Is there any way to get Intellisense in Visual C++ for Visual Studio 2005?
I'm trying to get the Boost libraries to load up with intellisense and in the object browser/class view.
I installed the binary for Windows with the BoostPro installer (BoostPro 1.40.0 Installer).
I'm not certain that it comes with the source code however, which may be required to make Intellisense work in VS2005.
Boost is open source, and mostly header only. Just make sure IntelliSense knows the directory where boost resides so it can explore it.
As an un-answer, you might try out Visual Assist X, which works far better and has more features that Visual Studio's IS.
To make sure Intellisense can find boost, just make sure Boost is in the include directories (under Project Properties->C/C++->Additional Include Directories). Maybe move it to the top. After that, close your instance of Visual Studio, and search the a *.ncb file near your project, and delete it. This will cause IntelliSense to refresh. This should hopefully be enough for it to assist you. (You have to include boost headers into your source files with #include for IntelliSense to consider it)
Keep in mind boost has some very complex parts that IS will choke on, but should still provide the names.
Intellisense scans the headers #included in source files in Visual C++ projects.
So create a project with a single source file that includes the top level header of the boost library that you're interested in. Some of the boost code can't be parsed by intellisense though, and the boost code contains a lot of code to workaround language or compiler limitations that's just noise to someone wanting to see the user facing structure of the libraries.
Related
InstallShield must be the crappiest "industry standard" application in existence, for reasons too numerous to enumerate here. However, one of those deficiencies is something I'd like to be able to fix, and with my first foray into writing an extension for Visual Studio (currently using 2015 version).
InstallShield has created a .isproj type, to allow integration with Visual Studio. This allows a developer to create an installer that references the output of a project as the files to include in the installer (rather than having to manually select individual files to include). This works well enough as long as the .isproj is being built in Visual Studio, and in a solution that references the project for which you need the output.
However, I also have an automated build for my installer projects, that we run on a build server using MSBuild. When attempting to build this way, we were getting completely opaque error messages indicating that the project output references above couldn't be resolved.
As with all InstallShield errors, Googling for answers turned up nothing except for multitudes of other people having the same problem. So I decided to dig into the plain text of the .isproj to see what I could find.
As it turns out, the .isproj type is a just a regular MSBuild script, and it even has lines commented out that explain options that can be added to the project; one of those things that can be added is an ItemGroup containing ProjectReference nodes. Manually adding the nodes helped solve the problem. Command-line build now works.
However, I am dissatisfied with a) having to manually type this stuff in, b) having no visual representation of what projects are being referenced, and c) not finding out about a problem until the build fails. So, I would like to be able to extend Visual Studio to help me with this. Here's what I'd like to do:
1) Add a "References" node to the project in Solution Explorer that acts like the References node for any normal .csproj.
2) Restrict the available References to other projects in the the current solution.
3) Visually represent a project with missing references (e.g. by underlining the project name with a colored squiggly, as with errors/warnings), and potentially failing the build if missing (depending on whether I want to treat it as an error or a warning; TBD).
To these ends, I've downloaded MPF for Projects - Visual Studio 2013, which provides an SDK for creating a new project type.
However, before digging too deeply, I need to know if it's even possible to EXTEND an existing project type, as described above, as I obviously don't have InstallShield source code. Also, any links or guidance as to a starting point for doing so would be greatly appreciated.
YES, I have seen the posts that all you need to do is link it. Find you .lib and link. I have 10 years IT experience and its not at all clear to me where/how the link settings are made. This is a DLL that is not in another project. I have the lib and I have spent hours just trying to find out how to pull this in. Just curious, why there is not some tab saying external libraries, and a browse button to goto whereever you stored this on your file system? I just don't get the multiple steps to get this file linked up. Someone please spell it out. I'm on Visual C++ Express 2010.
Did you try just using "Add Existing File to Project", browsing to the .lib and adding it? Visual Studio recognizes the file type and passes .lib files to the linker.
There's another way which is more complicated and also more powerful. You can open the project properties by right-clicking the project in Solution Explorer. Then go to the Project Directories and add the path to the LIB paths, then go to Linker Input and add the library name (without path) under additional inputs. The advantage of this second method is that you can have different versions of the .lib and .dll for release vs debug, or 32-bit vs 64-bit builds.
In addition to Bens answer, you can also use pragma directives:
#pragma comment ( lib, "path-to-library-file.lib" )
Some prefer linking libraries in the project, others prefer it in the source file. It doesn't make much of a difference either way.
I understand the C++ and C syntax, but im a little unsure how i am supposed to code in the VS2010 environment, when i create a project i am presented with folders such as headers and sources.
What c++ code goes into which folder?
Also, how would it work for C?
.h files go into headers, .cpp files go into sources.
Project->Add Class will do the work for you
I agree that Visual Studio can be a bit overwhelming if you're used to code C/C++ using a simple text editor and calling the compiler via the command line.
Decide for yourself how you want to continue with Visual Studio.
If you want to create simple C/C++ applications (consisting of only 1 or 2 source files), just create an empty project and choose "Add Item" to add a source (.c, .cpp) or include (.h) file.
If you want to evolve to more complex applications with e.g. using the MFC libraries, .Net, WPF, ... learn how to use the Visual Studio wizards. These wizards can set up a complete environment for you so you only have to fill in your business logic. Consider reading a Visual Studio 2010 tutorial to get you started.
We have a library for a complex COM object that we are importing using the following:
#import "library.tlb"
this works fine, VC++ compiles a tli file and somehow that gets magically included in the build process, so code written against the tlb works.
However, intellisense doesn't pick up the library entries. This is a crazy complex COM component, and having intellisense would help immensely. Can anyone provide some pointers on how to get intellisense to work properly with this?
I have tried deleting the .ncb file, and that had no effect.
The commercial (not free) addin Visual Assist may be worth looking at. It works in VC6.
I am getting an error while porting my application from VC6 to Visual Studio 2005.
Does anyone have any idea what this means?
mfcs80.lib(dllmodul.obj) : error
LNK2005: _DllMain#12 already defined
in MSVCRT.lib(dllmain.obj)
From http://support.microsoft.com/default.aspx?scid=kb;en-us;q148652
A LNK2005 error occurs when the CRT
library and MFC libraries are linked
in the wrong order in Visual C++
Because
The CRT libraries use weak external
linkage for the new, delete, and
DllMain functions. The MFC libraries
also contain new, delete, and DllMain
functions. These functions require the
MFC libraries to be linked before the
CRT library is linked.
So
There are two ways to resolve this
problem. The first solution involves
forcing the linker to link the
libraries in the correct order. The
second solution allows you to find the
module that is causing the problem and
to correct it.
Either
Force Linker to Link
Libraries in Correct Order
On the Project menu, click Settings.
In the Settings For view of the Project Settings dialog box, click to
select the project configuration that
is getting the link errors.
On the Link tab, click to select Input in the Category combo box.
In the Ignore libraries box, insert the library names (for example,
Nafxcwd.lib;Libcmtd.lib).
Note The linker command-line equivalent in /NOD:.
In the Object/library modules box, insert the library names. You
must make sure that these are listed
in order and as the first two
libraries in the line (for example,
Nafxcwd.lib Libcmtd.lib).
To set this option in Visual C++ .NET,
read the "Setting Visual C++ Project
Properties" online help topic.
Or
Locate and Correct the
Problem Module To view the current
library link order, follow these
steps:
On the Project menu, click Settings.
In the Settings For view of the Project Settings dialog box, click to
select the project configuration that
is getting the link errors.
On the Link tab, type /verbose:lib in the Project Options
box.
Rebuild your project. The libraries will be listed in the output
window during the linking process.
I'm sure there are a number of reason this could happen - the worst one I ever found was when trying to integrate a number of static libraries (ours) that were originally DLLS (in fact, we build the projects as both DLL & static libraries).
Our C++/CLI DLL was using the static versions of these libraries (To avoid DLL dependency issues that were causing ASP.NET loading issues when the C++/CLI Dll was being used) and was initially seeing the same linker error.
The problem turned out to be the use of AFX_MANAGE_STATE(AfxGetStaticModuleState()) macro that was needed when the code was built as a DLL but not actually needed for the static library call.
To solve this i ended up adding the following code to the stdafx.h of each project.
#ifdef OMUTILITIES_LINK_STATIC
#undef AfxGetStaticModuleState
#define AfxGetStaticModuleState AfxGetModuleState
#endif
This, of course, may not be your specific problem. But the way i eventually figured it was by turning on the /VERBOSE option for the linker and seeing who, what, where & when it was pulling in the runtime libraries. (Project Properties/Configuration Properties/Linker/Show Progress in vs2005)
You could set the linker input to ignore the troubling library in the project properties, but this may or may not work.