As developers stated here,
The cool thing about all of this is that you have the choice to use the Visual Studio Code branded product under our license or you can build a version of the tool straight from the vscode repository, under the MIT license.
Here's how it works. When you build from the vscode repository, you can configure the resulting tool by customizing the product.json file. This file controls things like the Gallery endpoints, “Send-a-Smile” endpoints, telemetry endpoints, logos, names, and more.
When we build Visual Studio Code, we do exactly this. We clone the vscode repository, we lay down a customized product.json that has Microsoft specific functionality (telemetry, gallery, logo, etc.), and then produce a build that we release under our license.
Given that I'm not able to build from source by myself, if I install VSC and replace product.json with the clean version, will I have the same effect?
Shortly:
Code - OSS is an open source project without any proprietary code.
Visual Studio Code is a distribution of the Code - OSS repository with Microsoft specific customizations released under a traditional Microsoft product license.
Also you can find more information here
Related
Is there a standard way to handle Visual Studio Code inside a company network, in which VS Code is not allowed to contact the Internet?
For e.g. Eclipse, we can host our own update sites for plugins and can package pre-configured versions of the IDE for the developers.
Is there something similar for VS Code?
There are two ways (I know of) how you can provide pre-configured VSCode-installations
A) VSCode inside a Docker container. You'll have a minimal standard installation of VSCode on your computer, all plugins and settings come with the Docker image that is loaded into your local VSCode installation. See docs here: https://code.visualstudio.com/docs/remote/containers
B) VSCode web. This is a zero-installation version of VSCode which is running in the web browser. See docs here: https://code.visualstudio.com/docs/editor/vscode-web You can try it on GitHub: open any repo and change .com in the domain to .dev
I have several projects on GitHub and on Visual Studio Team Services. In VS 2015 I simply connected to a server, selected and connected to a project. In Team Explorer I saw all solutions in Solution part. In Visual Studio 2017 I don't see any solution. If I check it again in VS 2015 (on the same computer), it works fine. Is there something more to do in VS 2017 to see the solutions in Solutions part?
You appear to be using TFVC for this example.
Have you defined a workspace – or at least looked at the workspace in Source Code Explorer – so VS2017 knows you have the local files?
(AIUI the solutions list is based on a search of the local workspace.)
Tried to find where I read this yesterday but I can't remember, but according to Microsoft on the developer forums, this is as intended. You need to click "show folder view" to see your solution.
I recently installed Microsoft new "Visual Studio Code" on Windows. The entire setup was quick and nice. What technology is that? Is it clickonce? It was smooth and quick
It's using Squirrel to create a self extracting zip archive containing a nuget package. Squirrel only supports per-user installation and because of that it doesn't impress me.
Enterprises want per-machine installations with auto-update disabled so that change can be centrally managed. Technologies like Click Once and Squirrel just ignore this and do limited things in the per-user context with auto updates enabled. Two different animals.
I've been developing on Visual Studio, and here comes Visual Studio Code which is described as a source code editor that supports multiple platforms. For me, I find it promising considering it's a lightweight editor compared to Visual Studio.
Since Visual Studio Code is still a baby, is it safe to say as time passes by and this baby becomes mature, this will be the new Visual Studio considering it can run on multiple platform?
Does Visual Studio Code has a roadmap on the upcoming features?
Visual Studio Code will not replace the regular Visual Studio, if that's what you're asking. VSCode is intended to be a very lightweight, code-focused IDE. There are a plethora of features present in Visual Studio that I don't expect we'll ever see in VSCode simply because they are not within the scope of the project. For example, I don't think you'll ever see the designer in VSCode, which is something you would sorely miss if you were developing a WPF or WinForms application.
Right now VSCode seems to be mostly targeting web application developers using ASP.NET 5 and node.js.
As for what's ahead for VSCode, I'm not sure if a roadmap has been laid out anywhere but I do know that a plugin/extension system is in the works, along with ES6/7 support and a few other things.
If you want to follow the development of VSCode, check out their blog, Twitter, and UserVoice.
What would be the most frictionless workflow for working with NuGet and Visual Studio 2005? Is this at all possible? I understand that the plugin is only available for Visual Studio 2010, but there is still the package manager console wich seems to be nothing more than powershell. Can I run the console without Visual Studio and can the console download and integrate packages into visual studio 2005 projects? If so, how is this done?
Scott Hanselman blogged about adding NuGet "support" to Visual Studio 2008. You can probably adapt this slightly to work in Visual Studio 2005 too, though of course you won't get the same experience as in Visual Studio 2010.
Well, not really. A better title would be "How to Cobble Together
NuGet Support for Visual Studio 2008 with External Tools and a
Prayer." The point is, there are lots of folks using Visual Studio
2008 who would like NuGet support. I'm exploring this area and there's
a half-dozen ways to make it happen, some difficult and some less so.
The idea would be to enable some things with minimal effort. It'll be
interesting to see if there are folks in the community who think this
is important enough to actually make it happen. Of course, the easiest
thing is to just use 2010 as it sill supports .NET 2.0, 3.0, 3.5, and
4, but not everyone can upgrade.
Someone could:
Backport the existing NuGet Package References dialog to 2008 using
that version's native extensions (not VSiX)
Create MEF (Managed
Extensibility Framework) plugins for the nuget.exe command-line to
update the references in a vbproj or csproj
Use PowerShell scripts and
batch files to get the most basic stuff working (get a package and
update references.)
Maybe write a shim to get DTE automation
working...
But that's coulds and maybes. Let's talk about the MacGyver
solution. more »