I've been writing C/C++ for years using Xcode and am very comfortable with *nix systems. Now I'm working with people who only understand Windows; I've decided to try to learn that environment too.
I was thinking that google would be my best friend, but even the terminology for VS is sufficiently orthogonal to that of Xcode that I can't make any headway. (E.g., what's the equivalent of "Add new Target to project" for VS?)
Can anyone point me to a guide to VS for Xcode practitioners? I've seen lots of translators going the other direction.
Thanks!
I do not know of any XCode to VS Guide, but according to XCode Documentation:
A target specifies a product to build and contains the instructions for building the product from a set of files in a project or workspace.
The analogous concept in Visual Studio would be a project. In Visual Studio, a project contains code files, assets and settings which compile into an output of some sort. (Could be an executable, a DLL, a website, or a few other options...) Projects can reference other projects or other external libraries (System or user libraries) which are all delivered together at compile time.
A solution contains multiple projects which can be related (referenced) and compiled and linked together.
When you first start VS, it will ask you to Open or Create a project. It usually will automatically create a solution and automatically add the project to it. To add additional projects, you can right click the solution in the "Solution Explorer" and add another project.
Hope this helps
I believe what you're looking for is the Build Configuration Manager in Visual Studio. (It's been a while since I've used XCode). As I recall a "Target" in Xcode is how you want the project built. In VS you get a Debug and Release configuration by default but you can use the Build menu and choose "Configuration..." to create more.
I don't know of a tutorial for XCode users but Kate Gregory has some nice beginner screencasts on pluralsight for using Visual Studio 2010. Those may get you over some learning curve hurdles. I think they have a 30 day free trial. If you move on to .NET development they have a lot more that can really help you get up to speed quickly.
Quick Terminology
In Visual Studio you typically create a Solution. A solution can consist of any number of Projects. You can add projects for .DLLs (libraries), services, applications (gui and console based). You can have multiple applications but can only designate one as the Startup Project.
In my typical project I start with the GUI and Add a project of the type I want. Then I often add a library project for new code that I think I can use across multiple applications. Existing code in both supplied libraries and ones you've built are added as References. You can right-click on References in the Solution Explorer and select Add References.
In XCode (when I used it) your IDE consisted of two pieces, XCode and Interface Builder. In Visual Studio you can build interface elements directly in Visual Studio ( but there is also a tool called Blend that allows for UI creation and modification). There are THREE major types of interfaces web (usually an ASP.NET application), WinForms and WPF. I think of WinForms as the equivalent of what you build in IB. WPF is the most recent addition and has lots of advantages but a somewhat steep learning curve.
This is probably oversimplified because VS does so much and I'm mostly familiar with the C# and C++/CLI capabilties. However it also supports Visual F#, Iron Python, Iron Ruby, Visual Basic, Sharepoint, Office Integration,Silverlight, XNA, etc.
Visual Studio is very extensible. There are lots of extensions to make it integrate with other tools. There are also a couple of extremely useful extensions that make refactoring and writing code easier, my personal favorite is ReSharper from JetBrains.
Related
I'm learning F# and I'm just trying to build Animate a pendulum program.
Here's the code:
https://rosettacode.org/wiki/Animate_a_pendulum#F.23
As far as I understand, VS 2019 doesn't support WinForms in F# (maybe, I'm wrong), so I have error messages, trying to copy/paste that code:
What should I do?
Thanks a lot !
If you're looking to use Winforms on .NET core, you'll need to do the following in your project:
Open the project file (double-click on the node in Visual Studio)
Change the Sdk to Microsoft.NET.Sdk.WindowsDesktop
Ensure you have this OutputType: <OutputType>WinExe</OutputType>
Add the following property to the top-level PropertyGroup: <UseWindowsForms>true</UseWindowsForms>
There won't be a visual designer to use, but you should have access to the APIs.
Unfortunately, there is no Winforms designer in Visual Studio 2019 for F# projects of any type, and Winforms can only be easily accessed (as far as I know) in .Net Framework (NOT .NET Core) projects they can be accessed as per #Phillip Carter's answer.
However you can still make Winforms programs easily by manually adding the references to your .NET Framework project, or (more easily) by manually compiling with the F# compiler, fsc.
The Fast Way
The easiest way to do this is simply compile the source code with the F# compiler from a single source file with fsc.exe. The F# compiler will automatically resolve dependencies for things like System.Windows.Forms and a lot of other commonly used namespaces. You can also provide lots of compiler directives for requiring other resources as well.
Example using VSCode, with various extensions:
Another Way
Start a new F# console .NET Framework project (don't pick .NET Core).
Right click on "References" in the Solution Explorer and click "Add Reference..."
Under assemblies, look for "System.Windows.Forms," select it...
And also select "System.Drawing" and then hit OK
Now you have access to both of those namespaces.
Before you run the project in Visual Studio, you should replace
[<STAThread>]
Application.Run( new PendulumForm( Visible=true ) )
with
[<STAThread;EntryPoint>]
let main _ =
Application.Run( new PendulumForm( Visible=true ) )
0
This way you (and VS) know where main actually is. It's not necessary for this small of a program to actually run it, but as your projects get larger VS will complain more about where things are located in your project.
We have a Windows Desktop only product suite that consists of several .exe applications and (obviously) quite a bunch of shared libraries between these apps. There's about 20 exe apps and maybe also about 20 shared libraries that are each used by several of these apps (some libs are very specific, some are just your good(?) old FooUtils.dll) Most code is C++, some C#.
Currently, all these reside in a single Visual Studio 2005 solution and are all built and released together. That works quite fine and each developer always can edit / see / debug any code he needs to. About 15 devs (mixed C++ / C#) on that product suite.
Now the problem
Due to migration pressure (language features, new 3rd party components) it becomes increasingly urgent to migrate some of the apps (read .exeprojects) to newer visual studio versions. Some to VS 2010 maybe (3rd party dependencies) some to VS2015. And some we just have not the resources to migrate them from VS2005 yet (third party constraints, as well as time/budget constraints).
This means that several of the shared C++ libraries will have to exist for several visual studio versions. (As opposed to the exe projects - these would just be built/maintained for one chosen VS version.)
Now the question
Given a set of (internal) shared libraries that need to be created for multiple different Visual-C++-Versions and that should be easily editable and maintainable for all devs, how are we to keep the Utils.vcproj(2005) the Utils.vcxproj(2010) and the Utils.vcxproj(2015) in sync?
Mostly to avoid manually having to maintain all files contained in the projects, but also regarding project settings / .[vs]props settings for these projects.
Ideas we had so far:
Just accept annoying triple maintenance of 3 project files in 3 different solutions (ugh.)
Use one of the vc.. project files as the master project and automatically (how??!) generate the other vc..files from it.
Use tools like CMake, Premake, ... ?? to generate these shared-shared library projects. (That would mean introducing a foreign configuration tool for our devs)
If you want to avoid manually updating your project files in separate versions of Visual Studio, you'll have to have a master configuration for the project of one sort or another. The two options you listed are basically your options:
Use one project version as the 'master'. In this case, the master must be the oldest version (VS2005 in your case?). Visual Studio has a project upgrade feature, to convert older projects to newer versions. When you load up an older project in a newer version, it prompts you to upgrade. This process can be automated with some simple scripting. Using devenv.exe <project/solution file> /upgrade you can upgrade a project from the command line.
Use CMake/Premake/etc. These add a little bit of overhead, but making supporting new platforms and configurations a lot less painless. If adding new dev tools is cumbersome to your process, and you're only supporting Visual Studio, the first option might be more suitable.
I'd like to get started with the Visual Studio 2010 SDK and creating integration packages. All I would like to do for now is provide a new project type and language service. However, I don't know how I should design it...
The package will provide an editor for a programming language that compiles for x86 or ARM processors. The problem is that there are a few language differences depending on which processor you're developing for. I'd rather not have a separate project type for each architecture, however. Preferably, the programmer chooses the architecture when they create the project and the package automatically loads up the specific parts such as the correct language service, configuration settings, and whatever custom tools and dialogs are associated with that architecture.
How would I go about doing this? I've read about "flavored projects", but I don't really understand how to implement them. Is that what I need?
A couple of points to note to get you headed in the right direction:
The interfaces for a language service to hook into the editor have completely changed for VS 2010. I would recommended asking questions on the VS Editor Forum where all the devs for the core VS editor hang out for the speediest answers since the documentation and samples are still incomplete at this point. (There is a compatibility layer to support "old" language services, but you'd be better off just using the new interfaces since you're starting from scratch.)
A "flavored project" (referred to in the docs as a Project Subtype) is a way to add/remove functionality from an existing project system. For example, there is are project flavors for Web Projects, WPF, Devices, Database, etc.... on top of CSProj and VBProj. In these cases C# and VB are the "base" project systems and WPF, Web, Database are flavors that extend the base C#/VB project systems. Since you have a custom language, you should implement your own base project system. Your best bet for starting from scratch would be to build something based off the MPFProj source library.
I'm working on something very similar -- here is my starting point:
http://blogs.msdn.com/noahric/archive/2010/02/15/markdown-part-4-outlining.aspx
It's a very nice example of how to implement an editor extension.
I'm curious about your thoughts on moving to a new IDE (specifically Eclipse). I have been hearing wonderful things about it from this community and I'm always on the lookout to try new things.
Currently I'm running Visual Studio 2005, with a bunch of external commands loaded (for compiling down to a binary, running lint, etc). We're developing C code for microcontrollers.
I've read over some of the other threads on here about the advantages and disadvantages to Eclipse and Visual Studio (specifically SO - best IDE thread and SO - best C IDE thread), but I'd like to hear your thoughts on using it for programming an embedded environment. I'd imagine that there is a simple way to use the external tools that Visual Studio currently uses (it simply calls various batch files that we've created).
Is it worth it to specifically switch over to Eclipse?
Answer to you question about way to call external tools: no problem - from eclispe you can anything: external program, batch file etc. Moreover, if you use custom build generator - you could use it transparent with eclipse.
I don't think I would switch from Visual Studio to Eclipse in hopes of getting a better IDE. Typically an embedded manufacturer makes plugins and toolchains that work specificially with Eclispe, that's what makes it worth using in the Embedded world. For example with the NetBurner plug-ins, when creating a new project you can just select New NetBurner Device Excecutable, or New NetBurner Library, all the default includes and libraries get set up for you and the proper cross platform tool chain is set up for you automatically. In the NetBurner case it also uses the Eclipse managed build process (as opposed to make files) which I find nice. There is also support for using make files if you prefer that option.
While I have a couple of tools set up to run as external tools (lint, an auto version updater, DOS prompt etc) most steps can be triggered from pre-build or post-build steps or there are many many add-ons for common needs like source code management, bug tracking, etc. There is great support for SVN, Trac and Mylyn for example. I use both VS2010 and Eclipse. I like them both but VS2010 is the better IDE. It's a little hard to compare because I do C# (and a little C++/CLI )in VS and C++ in Eclipse. That said, I wouldn't relish the though of trying set up VS to do my embedded tasks.
I've been programming in Linux/UNIX for several years now, but recently I needed to do some stuff in VS2008. I had difficulties with understanding how VS organizes work. Do you know any resources (free web pages preferred, but books also acceptable) which would show me a general picture and explain at least some details? Examples welcome, comparison with typical UNIX stack very welcome.
I don't need a language (C#/C++/VB/...) reference/guide; I've seen some of them and none of them seem to suggest how to work with VS efficiently.
You might be interested in introductions to MSBuild, the project format of Visual Studio. Whereas in UNIX you have a autoconfig script, and Makefiles, VS2008 allows most configuration through right clicks and menu options.
A second area of interest will likely be build configurations. Instead of re-running the configure script on different targets, or for different stacks, you specify targets with the configuration manager. Once you select a new configuration ("x86", or "Release", or custom ones like "Production"), VS churns for a while, as it updates the Intellisense of your new preprocessor definitions, for example, and Resource files. Your "Debug" configuration will likely define the macro "DEBUG", so you can use regions surrounded with #ifdef DEBUG, for example.
Visual Studio organizes common groups of source files into "Projects", which can be referenced by one or more "Solutions". Projects establish interdependency on one another, and external libraries. If you look at the structure of the projects in the Microsoft Enterprise Library, you will notice that there are several different Solution files (*.sln) which encompass different groups of common project files. You might have a different solution file, for example, if you want to reduce load/compile time, by not loading the unit test projects with every build.
So, analogies:
UNIX way:
# ./configure
# make
# nano Makefile
# make
VS2008 way:
# (Set up "Project Properties", Conditional Compilation Symbols, Build Paths, all from GUI application)
# (Click Build)
# (Change Configuration)
# (Click Build)
I don't have any links for you, but:
Visual Studio can open one and only one Solution at a time
A Solution may have zero (not very useful) or more Projects
Code (in whatever language) goes into projects
Projects can have any number of files and/or directories
Projects can reference files anywhere, not just within their own directory structure (though few do)
Visual Studio is a very flexible and powerful IDE. I think the best way to get the big picture is to build that big picture yourself in your own terms by using the heck out of it.
Build configurations and project properties are definitely two areas you will want to focus on.
You should explore the various options and configuration switches for generating assemblies and how they are managed in general. Learning the various build options and how assemblies are managed can save you headaches down the road.
The VS debugger is a thing of beauty and I recommend investing some time in exploring its capabilities. I recommend you familiarize yourself with:
Breakpoint management (especially the breakpoint window) and also conditional breakpoints
The Watch and Locals windows
Thread and Memory windows and tools
Immediate window (often overlooked and underrated if you ask me)
Finally, you should take a look at some tried and tested tools and plugins and get familiar with them. I would personally recommend ReSharper, Dependancy Walker, and .NET Reflector. ReSharper is an excellent productivity tool and Dependancy Walker and .NET Reflector are excellent analysis and debugging aids
Here's a couple of handy stackoverflow threads:
Do you have any recommended add-ons/plugins for Microsoft Visual Studio?
Favourite Visual Studio keyboard shortcuts
Have you considered installing cygwin and gcc? If you're looking to write a console app, it might just do the trick.