interface for Visual Studio Errors (want to replace compiler) - visual-studio

I was wondering if anyone knows how to use a new compiler within visual studio, and how the interface between compiler and IDE works to make error messages and source code locations "work" (eg double click goes to location).
Context: trying to integrate clang

I am using NMake for "integrating" clang with Visual Studio. You get the convenience of syntax highlighting and intellisense with the power of LLVM. You have to manually make an nmake buildscript file though (which is quite cumbersome).
There is a clang switch called -fdiagnostics-format=msvc that will output the error and warnings in a format that Visual Studio understands (so you can quickly jump to errors or warnings in your code).

Microsoft provides a Visal Studio Integration SDK which presumably is used by Intel. The Intel compilers can add themselves to the VS IDE and replace the Microsoft compilers.

Related

Debugging Makefile project (mingw-gcc) on Visual Studio

I installed MinGW and created a makefile project on Visual Studio Community 2015 today and got it working for compilation.
Still two things are bugging me:
Interface
I can't tell Visual Studio to prevent closing the console window after running the program. Even Start Without Debugging closes the window and the project properties are not the same as a normal VS project, so I don't know how to configure this.
Debugging
Setting breakpoints is hopeless. Apparently the debugger won't understand debug info from files compiled with other compilers. I get Module was built without symbols..
I've tried setting up gdb according to this answer, but then starting the debugger lead me to this window:
which indicates that the executable has indeed debugging symbols (I'm compiling with -g)
I can feel I'm getting pretty close. What am I missing?
mingw-gcc generates DWARF format debugging information in its
executables. The Visual Studio debugger expects separate PDB
debugging files as produced by Microsoft's compilers. It can't
recognize DWARF.
You can debug MinGW executables either with
the gdb console, as you have almost started to do, or for
"visual" debugging you can do it in an IDE that supports gdb,
on Windows, such as CodeLite, Eclipse-CDT, CodeBlocks. If you
are wedded to Visual Studio you might try your luck with
Microsoft's open sourced Visual Studio MI Debug Engine ,
which according to its blurb "enables debugging with debuggers that support the gdb Machine Interface ("MI") specification such as GDB, LLDB, and CLRDBG".
I know nothing more about it

What tools are available for F# debugging?

Are there gdb (or similar) for F#?
What tools/programs do F# programmers normally use for tracing F# code in Mono?
Does Visual Studio 2010 provides some integrated debugging tools for F#?
Visual Studio 2010 provides a fantastic debugging experience for F#, including breakpoints, tracepoints, call stacks, locals, stepping, set next statement, threads window, poking new values into variables, debugger visualizers, conditional breakpoints, immediate window, ... the only caveat is that the last two use the C# expression evaluator (F# does not have its own debugger EE), which means you must type e.g. C# syntax into the 'immediate window'.
(Everything I mentioned above is available for free if you download the free VS2010 Integrated Shell and the F# CTP.)
I am not sure what is available right now for Mono, but would not be surprised if there is something decent already, and something even better coming in the not-too-distant future.
Mono has its own debugger. The debugging format situation is slightly confusing because Visual Studio will generate pdb files which are needed for their debugger. Mono uses the alternative mdb format. fsc.exe (The f# compiler) will generate the appropriate ones for whichever platform it is run on.
The Monodevelop IDE can be used for general debugging of .net assemblies, even though it doesn't support a released f# version yet. You'll need to refer to your project's generated assemblies in the project.
Note that you also have to pass '--debug' to mono if you're executing it on the command line and want, for example, file names and line numbers in stack traces.
Any .NET debugger should work on F# code. The Visual Studio debugging experience is basically the same as for any other language (e.g. you can set breakpoints in the editor, etc.). I can't speak to what tools people use on Mono.
LinqPad understands F# code but I did not try it. A paid version gives you debugging.

No IntelliSense for C++/CLI in Visual Studio 2010?

I just moved from Visual Studio 2008 to Visual Studio 2010 (final) and noticed one major flaw:
When I try to use AutoComplete in a C++ source file for managed C++, a small note in the footer appears:
IntelliSense for C++/CLI is not available
Uh, has IntelliSense for C++/CLI been dropped from Visual Studio 2010? Is there any way to get this back? It is rather useful...
You are correct. Unfortunately it has been dropped. You can check this opened issue on Microsoft's Connect website.
I'll just quote them for the sake of the answer:
Unfortunately in this release we had to cut the intellisense support for C++/CLI due to time constraints. If you want to get some intellisense like quick info and memberlist on the native classes you can get it by choosing no /clr support in the project properties.
About getting back intellisense, your best chances for now are using third-party tools like VA Assist for example. I've tried it with Visual Studio 2008 and its IntelliSense is a whole lot better than the default one.
It is available again in Visual Studio 2012.
If you want to get IntelliSense back, install Visual Assist X from Whole Tomato Software. Here you can get a 30-days trial to check the intellisense.
According to the Visual C++ Team Blog, C++/CLI Intellisense will be in the next version of Visual Studio, but not in a service pack for VS2010. That blog post also gives some detail as to what went wrong and led to this sad state.
I don't know if you can use this settings but it work for me. I only check the Common Language RunTime Support for the cpp files that use it. I do not check it for the whole project and I've got intellisense for all the files that don't use the CLI.
Yes! you can enable the IntelliSence, but in a tricky way. Follow these instructions:
Go to your project properties. (Right click on your project name in
Project Explorer, and select Properties. or simply Alt + Enter)
From Configuration Properties, select General
In the right-hand section, find "Common Language Runtime Support"
and change it to "No Common Language Runtime Support".
Click the OK Button.
Now the IntelliSence is working. But a problem is an error when you compile your code! (The error is: error LNK1123: failure during conversion to COFF: file invalid or corrupt)
You can simply go back to Project Properties an change Common Language Runtime Support to "Common Language Runtime Support, Old Syntax (/clr:oldSyntax)".
Good luck.
This solution is only if you don't want Common Language Runtime
It worked for me in VS2010
Go to Project Propreties > Configuration Properties > General > Common Language Runtime Support and set it to No Common Language Runtime Support.
This will work fine just after hitting Apply button.
As mentioned you could install some paid software such as "Visual Assist X from Whole Tomato Software".
or
You could use open source tools that contain intellisense*, one such tool is Qt Creator 3.3.1 (opensource). You have two options, either setup your entire project with Qt to compile using VS2010 compiler, or use Qt to link to your source files and compile with VS2010. You write your code in Qt, save, flip windows to vs2010 and compile and debug.
When changes are saved in Qt, vs2010 will automatically reload the source file in the project and you can compile.

Visual Studio, Intel Visual Fortran, and Visual C/C++ mixed-language compile

Working with Visual Studio 2008 Pro, with Intel Fortran compiler v11, on Windows 7 x64.
I have an Intel Visual Fortran project set up with all the fortran source files. I wish to gradually replace all these subroutines with C/C++ (actually cuda -- bonus points). Simply right clicking on source files in the solution explorer and "add existing item" will put a .cpp or .c or cuda file in the list... but it never gets compiled. Thus any INTERFACE to C code written into the fortran code always fails on the link step.
How does one get a mixed-language project like this? Google has failed me, and all I find are descriptions of the actual interface code, with no instructions on how to implement the visual studio build system.
Thanks in advance.
A Visual Studio project can only contain code elements from a single language. To mix C++, CUDA and Fortran, you must set up a Visual Studio Solution. Then you are free to integrate multiple languages.
A useful guide to setting up a CUDA multi-language VS 2010 Solution can be found here.
[This answer has been assembled from comments and added as a community wiki to get this question off the unanswered list for the CUDA tag].

How can I suppress individual BizTalk warnings in Visual Studio 2005

We are currently using BizTalk 2006 R2 to build Enterprise Integration solutions. We use BizTalk maps extensively, but when you build a solution in Visual Studio 2005, it produces the following warning against maps:
Warning Double-click here to show/hide compiler links.
In my opinion, these are not real warnings and can be ignored, but I don't like that strategy because ignoring warnings is a bad habit to get into.
Using a \nowarn property does not seem to be an option because the message does not have an associated number.
Also, when the project is built using a build script the warning disappears, suggesting that this is a feature of Visual Studio rather than a real compiler warning.
So I was wondering if there is a way to suppress this type of warning in Visual Studio.
I don't believe there's a way to suppress these for BizTalk projects. BizTalk gurus just learn to ignore them.
You can use the /nowarn option to suppress warnings.
See MSDN: /nowarn (Suppress Specified Warnings) (C# Compiler Options).

Resources