does visual studio have anything that shows snippets of code for the Windows API(like I think VB6 might have)?
For example you'd select an API function and it showed a code snippet.. i recall something like that from the VB6 days. It made it easier to test out any API function because it showed some example code to declare it and possibly even to use it.
I don't know if VB6 had, but there was a program called ApiViewer that did that
And there is currently a comparable program
https://www.codeproject.com/Articles/92967/VB-9-0-C-3-0-API-Viewer
that uses a website called pinvoke.net
And there is an addin to visual studio from the team that did the pinvoke.net website
http://pinvoke.net/
I have a C#/.Net 4.0 project in Visual Studio 2010. Parts of this project were originally from an old VB6 program that was converted to C#.
Sometimes I need to look at the old VB6 code side-by-side with the C# code, and so it's very convenient to just open and view the file in Visual Studio. V.S. even displays comments and keywords in appropriate colors for easy viewing. To open the VB6 file I'm doing a File>Open>File. The VB6 file has a .cls extension.
The problem is that when I do that it also tries to do background compilation of it, so as soon as I open it, it registers hundreds of errors because VB6 isn't a supported language and even if I do a Build Solution or Rebuild Solution it includes those results in the build so I can't build my C# project when the VB6 file is open.
1. Why does it do this, considering that the VB6 file is not part of the current solution or project?
2. How do I turn it off so I can view the file but not have Visual Studio try to compile it?
Why does it do this?
The cls extension is mapped to the Visual Basic language service. It will interpret any file with that extension as a VB.Net file and process it as such.
The Visual Basic Language service is always compiling files to a degree in the background. It doesn't actually produce EXE / DLL but will go far enough to provide semantic information to the front end. This is used in intellisense, code highlighting, error squiggles, etc ...
How do I turn it off?
Unfortunately you can't. Visual Basic background compilation is not configurable. Hence any file which it believes to be VB.Net code will be processed in the background and errors will be displayed.
The only way to view it without errors is to rename the file to an extension not thought to be VB.Net code (like txt)
I am a student & am newly introduced to the Microsoft Blend.
Its something really impressive & makes me design happily.
But I am facing a problem: Its fine about the designing part but what about the coding?
Where are we suppose to write the code? I mean how are we to import that file into Visual Studio 2010.
Please do tell me the solution ? I have been looking out for resources nearly everyday.
But its still in vague.
Thanking you.
Expression Blend is a tool meant for designers so it does not really focus much on features for writing code. It is actually designed to inter-operate well with Visual Studio and you should be able to just open any Blend project or solution in Visual Studio and do your coding there.
In fact, I often have both tools open at the same time with the same project open and it makes for a pretty smooth workflow. For example, if I make a change in Blend and then switch to Visual Studio it will prompt me to reload the changes.
If you have Visual Studio installed the easiest way is to click on a file inside the Projects tab and then choose Edit in Visual Studio (see image). Once you do that VS will load the project / solution and open the file for you to edit your file and or add code to it.
I need to modify some logic of Javascript Intellisense on Visual Studio 2008 SP1 like some build-in function such as ScriptEngine, ScriptEngineBuildVersion and etc. Moreover, I need to dynamically generate function depend on opened docuement.
In Visual Studio, language services are provided via VSPackages. Most built-in language services in Visual Studio 2008 do not really offer any kind of extensibility or customization that would enable what you're trying to achieve.
There are a couple of options you could consider though:
Write your own Javascript language service. Obviously, this would be non-trivial, but it would allow you to get the precise behavior you're after. Language services are responsible for parsing the file to provide colorization, quick info, Intellisense, auto-completion, and other features to the core text editor. The simplest example of a language service is a sample in the Visual Studio 2008 SDK 1.1 called the RegExLangService. There is also a detailed walkthrough for the sample.
You could attempt implementing either an Add-in or a VSPackage which would insert/manipulate text in the editor based on the contents of the open document. Your question doesn't really say exactly what kind of behavior you need (other than dynamically generating a function). This would certainly be possible with the Visual Studio SDK and much less work than writing your own Javascript language service.
Good Luck!
I tried to search but if this is a duplicate it is hidden by some noise. Alternate title to the question:
What skills to look for when needing integration with the Visual Studio IDE?
Visual Studio 2008 is written in both native and managed code, though the bulk is written in C++. There are several pieces of Visual Studio that have always been written in managed code (e.g. the property browser, the WinForms Designer). And of course, Visual Studio 2008 is stitched together with COM.
In Visual Studio 2010, there is an effort to move more of the IDE to managed code. The text editor and the shell (i.e., menus, toolbars, document and tool window frames, etc.) are written in C#. In addition, pieces of the C# and VB IDEs are being written in C# and VB respectively. The new language, F#, is written completely in managed code -- the compiler, the language service, the project system, etc. -- are all written in F#.
You can use C#, VB or C++ to integrate with Visual Studio 2008. However, given that Visual Studio is built on COM, a good understanding of COM/ATL will be helpful. In addition, if you choose to use a managed language, a knownledge of COM interop and mixed-mode debugging will be extremely helpful. Note that there are a few levels of VS integration:
Macros -- the simplest way to run custom code in the IDE.
Add-in -- A simple but powerful way to build custom functionality into the IDE. With an add-in, you can create custom commands, listen to events, manipulate text in the editor, etc. However, you cannot add, say, a new language or editor to the IDE with an add-in. For many purposes, an add-in works fine.
Package -- this is the same level of integration as Microsoft's features use. With a package, you can create pretty much anything in the Visual Studio IDE, including adding new languages.
You should note that these become progressively more complex to author and deploy.
In Visual Studio 2010, a new form of extensibility is being introduced in several areas of the IDE, but primarily for extending the new WPF text editor. Going forward, integration with Visual Studio will require MEF (Managed Extensibility Framework) components rather than COM. So, in VS 2010, extending the text editor will simply require authoring a MEF component in your favorite managed language.
The podcast Herding Code episode #48 features an interview with Dustin Campbell, a program manager on the Visual Studio Managed Languages Group.
In that interview he talks for several minutes about this exact issue and gets into details about why the changes in 2010 are breaking compat with 2008 and how the future looks.
If this is strictly a curiousity question the other answers are correct. But if you want to dig a little deeper, listening to the podcast would be well worth your time.
At least the following languages are used inside of Visual Studio 2008
C++
C#
VB.Net
C
C++/CLI
C++ with managed extensions
Probably a few others that I forgot about.
A mix. The core is C++/COM stuff, but a lot of the newer stuff is managed code (C# etc). Due to the core being C++/COM (with a pile of code 'borrowed' from MS Office), VS integration is a funny experience.