Any idea why Visual Studio wants to add the packages folder to source control despite having disableSourceControlIntegration set to True in .nuget\NuGet.Config?
It was working properly. Then I added a new project and to that project added a reference to Entity Framework via NuGet, making two projects in the solution that use EF. This seems to have confused Visual Studio and now the packages folder shows up in the changelist whenever I check in changes.
Related
I am trying to create a packages file for the project & noticed that installed nuget packages in Visual Studio 2019 have got the project box unchecked.
I am positive that I am using these packages in the project.
For instance I am using the Entity Framework for the data access & update. I have ensured that all the packages are still being used in the project & the packages.config file has got all the packages listed in it.
Visual Studio ScreenShot
Installed nuget packages in Visual Studio 2019 project checkbox
unchecked
The window which you provided actually does not actually work as you described. And it is just designed by that.
What you need to note is that the projects that can be displayed on this window, such as 2020Portal.Data, 2020Portal.Mailbox, etc., have already installed the nuget package Entity Framework. Only projects that already have the nuget package installed can be displayed in this window. That's why they show up there.
And the checkbox functionality is only intended to enable the selected items to perform uninstall or update the nuget Entity Framework. It's just for the convenience of choosing certain operations to perform.
Hope it could help you.
We have a library project that we are working on, and in a different project I have the feature branch installed as a Nuget package. Changes are being made on the branch, but version number isn't being updated, so the Nuget package is getting updated, but it has the same name.
I've deleted the Nuget package from my packages folder, so I know I am downloading the latest, and if I manually browse (in the Object Browser) to the dll that I have downloaded to my packages folder, the Object Browser data looks correct.
I've uninstalled and reinstalled the Nuget package in my project, I've turned off all instances of Visual Studio 2017, but still old items are persisting in the Object Browser for my dll that I have installed through Nuget. I am expecting to have build failures because I'm referencing old items, but everything builds successfully, but then when I run the application I am getting run time errors because the old items I am referencing in code no longer exist in the dll that is currently downloaded.
It would be nice if we didn't have to bump version for every build, although we could set up TeamCity to do that automatically, but it would become difficult to maintain all of the extra Nuget packages in our feed.
So, short of just bumping version numbers on the dev Nuget packages, is there any way to clear the cache in Visual Studio 2017 so that the Object Browser updates to reflect the dll that is actually in the packages folder?
I found the problem. In the project where I was testing the library, I had a wpf project and a library project targeting .Net standard. Since the project I was actively working on was wpf I was zoned in on the packages folder in the solution directory, and forgot I was also referencing .Net standards in the same solution which pulls Nuget packages from C:\Users\[username]\.nuget\packages
Because of the project types, Visual Studio had two locations for Nuget packages. One at C:\Users\[username]\.nuget\packages and one at [solution dir]\packages
I updated only the solution directory packages, but apparently Visual Studio 2017 favors the use of the user directory packages, and that is where it was pulling the old API information. After deleting the package from my user directory everything is working as expected.
I have some merge module projects created using advanced installer. I need to integrate them with visual studio. I have done same for MSI projects and they work fine. but I don't know how to achieve continuous integration for MSM using Visual Studio.
Advanced Installer extension for Microsoft Visual Studio allows to create Advanced Installer Projects for Visual Studio. Each such project is a container that can include a single .AIP file.
The Visual Studio Solution can include one or more Advanced Installer Project for Visual Studio, in accordance with your needs.
Note that you need to remove the default project that is created when adding a new Installer Project to the .sln and add the existing project, the project that builds the .msm package.
edit
Indeed, you are right. It was a misunderstanding on our end.
On my machine I have several extensions installed side by side. One of these extensions also supports the build of a merge module project type.
We do not officially support this yet. The option to build other project types (e.g. Merge Module Project, Updates Configuration Project) with our VS extension will be available in a future version of Advanced Installer. I will let you know when we will add support for this.
Until then, you can use a build event as a workaround to build the Merge Module Project within the Visual Studio project.
To build the .msm project you can use a command line as described below:
http://www.advancedinstaller.com/user-guide/command-line.html#build-project
The command line can be something as below:
AdvancedInstaller.com" /build "$(SolutionDir)Merge module sample.aip"
I'm working on a TFS project with a small team. This project has a bunch of nuget packages installed, but it's for a 4.0 project, and the nuget package manager GUI doesn't even offer the older versions of the packages any longer since their 4.5 equivalents are now being used. In order to allow other team members to compile the project, they need to have the exact versions of the packages. I'd like to check in the entire "packages" folder used by nuget. Is this a good idea? If so, how does one check in the "packages" folder and all its contents since it exists at the solution level? There is no "Include in Solution" option in Visual Studio as there is when you right-click an assembly.
in the past I have also checked in the NuGet packages into version control. With this some problems appeared:
Some packages where not checked into version control when committing from Visual Studio into TFS.
Updating packages became a real problem.
For the first problem I had used the TFS Power Tools. The problem with this solution is that every developer needed to install the Power Tools.
A better solution came up with NuGet 2.7. It introduced package restore. With package restore there's no need to check-in the packages folder. They will be restored during build.
We use an on-prem TFS install with no internet access so we have to check in our package folders or our builds fail. The biggest issue is that VS does not behave consistently when it comes to adding the pending changes for new package files, often times it will ignore the .dll files in the pending changes window, sometimes it adds everything fine.
When I develop my web applications in Visual Studio 2010 I use tools such as GhostDoc, SandCastle, AJAX Toolkit, Moq, etc...
I usually use these tools in all my projects. When I downloaded the Moq tool for instance, I had a zip file with inside a couple of assemblies. Therefore, after unzipping the file, I added the relevant assemblies within the folder (in the file system) of the project I was currently developing, and then I referenced the dlls from Visual Studio.
Now the problem, or better organizational drawbacks, with this are 2:
1) I placed the assemblies within a specific project folder. That's ugly, since I would like to put the assemblies in one folder common to all the projects. Where do you usually put them?
2) Everytime I start a new project I need to reference all the assemblies over again. This, especially with the Ajax Toolkit is quite annoying. Is there any way to tell Visual Studio to add a set of predefined assemblies everytime I create a new project?
For the popular tools you can use NuGet. It will help you manage both the downloading, updating and removal of tools and referencing the appropriate assemblies.
Of the ones you mention, I found the following ones in the official NuGet packages repo:
Moq
AjaxControlToolkit