Git for Windows was installed as part of Visual Studio 2013. I think it is version 1.8.3 if I remember correctly. There are newer versions available. Is it safe to update git or will internal setting of Visual Studio get corrupted?
I had Git for Windows installed before I installed VS2013. I've been running 1.9.4 the whole time and never had an issue with VS2013 interfacing with Git. Updating Git externally of VS shouldn't be a problem, most likely VS just interfaces with a known Git repository and doesn't have a dependency on the Git version it self. If the newer version of Git has a new feature you want to use and VS doesn't support it then VS won't break, you will just have to run the command through the Git instead of through the VS GUI.
Related
After installing the latest VS update, VS doesn't see my git repo when I open project's folder. It offers me to create a new repo or to clone an existing one but not to open the one I have in folder.
Any ideas why it might be happening?
Is there a way to use the git submodule add command in Visual Studio 2019 without installing any add-ons? I use the GitHub tools provided by VS2019 and I would like to use just that and the built-in command line, but it seems that only some specific Git commands are supported...
I've been searching for the answer to this but so far haven't found one that has the same situation I'm having.
I have a DotNet Core 1.1.4 project and when I open the .sln project file in Visual Studio 2017 it pulls down the correct packages as soon as I open it. However for the command line if I run the commmand
dotnet restore --force
it is not pulling down packages. Strangely enough if I pull down packages using
dotnet restore --packages .\packages\
it will pull down several, but it appears to be the wrong packages. For example, in one of the .csproj files in this solution there's a reference to System.Interactive.Async 3.0.3 but the package that downloads is 3.0.0. Even if I run this
dotnet restore .\folder\project.csproj
it will not pull down this package that it later complains is missing when I go to build it.
This behavior is very confusing because as far as I can tell dotnet restore is supposed to do the same job Visual Studio 2017 is doing when it restores packages. The project folders do have a packages.config file but my understanding from prior searches is that dotnet restore ignores those. I've verified this reference is in the .csproj file as well the app.config file (not sure if that matters).
If I delete the contents of the .\packages\ folder and perform the dotnet restore .\folder\project.csproj command nothing appears in the .\packages\ folder even though when I open it in Visual Studio 2017 it populates there.
Why is this behavior different, and what do I need to do to get the dotnet restore command to restore the correct packages to the correct location?
If it helps here's the result of my dotnet --info command:
.NET Command Line Tools (1.1.5)
Product Information:
Version: 1.1.5
Commit SHA-1 hash: 2b517ddd29
Runtime Environment:
OS Name: Windows
OS Version: 6.1.7601 OS
Platform: Windows
RID: win7-x64
Base Path: C:\Program Files\dotnet\sdk\1.1.5
Found the answer to this. I downloaded NuGet.exe from here:
https://learn.microsoft.com/en-us/nuget/install-nuget-client-tools
Using the command
nuget restore
installs the correct packages where dotnet restore did not. I'm not sure why but it did fix my issue.
I have Windows10 with the Ubuntu bash and Visual Studio Code.
Every time I start Visual Studio Code it prompts a warning saying:
Git not found. Install it or configure it using the 'git.path' setting
I got git actually installed through the bash terminal:
# which git
/usr/bin/git
How can I instruct Visual Studio Code to use that git installed in the bash terminal?
I have tried through the git.path setting but I am not sure how to set the path to something that is relative to the bash terminal.
If you're running Visual Studio Code on Windows, you also need to install Git for Windows. VsCode currently can't access git on the linux subsystems.
I wan't to use Visual Studio 2017 (15.5) together with a Git repository which tracks some files with Git LFS.
I already have Git 2.15, which contains Git LFS, installed on the machine.
I've Visual Studio 2017 installed with only the following workloads and without the Git component since it already is available on the machine:
--add Microsoft.VisualStudio.Workload.ManagedDesktop
--add Microsoft.VisualStudio.Workload.NetWeb
--add Microsoft.VisualStudio.Workload.NetCoreTools
--add Microsoft.VisualStudio.Component.Wcf.Tooling
Visual Studio fails now to checkout branches from the repository since it cannot find Git LFS.
I assume this is because git-lfs.exe is not available on the path, and Visual Studio has its own Git instance in c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw32\bin\.
If I additionally install the standalone git-lfs installer, which makes git-lfs available on the path, checkout works on some machines but not on other (haven't found out what's the difference, maybe installation order or if it was a new installation or update of Visual Studio).
If I remove the c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\ folder everything works fine in Visual Studio, as it does use the Git version available from the path.
My questions are:
What is the supposed way to have Git LFS support in Visual Studio?
Is there a way to have Visual Studio using the Git Version on the path instead of installing its own instance
Does Visual Studio expect git-lfs on the path or should it also work with Git LFS installed through the bundled installer in recent versions of Git for Windows.
To get Git LFS working with Visual Studio 2017 (15.5.2) it requires Git LFS installed with the standalone Git-LFS installer. If Git LFS is installed with the Git for Windows distribution git-lfs.exe is not available on the PATH, and since Visual Studio has its own instance of Git, LFS functionality won't work.
It is also important to have Git LFS early in the path otherwise it won't be passed to Git by Visual Studio as the PATH passed to the Git instance run by Visual Studio is limited in the length. For example installing Git LFS after Visual Studio often ends with git-lfs.exe too late in the PATH.