Visual Studio Community 2017 "add package" when pressing Ctrl+Dot - c#

In Visual Studio Community 2015 Update 3, when you have a type that doesn't exist in your project, VS will search the package sources and give "add package xxx" suggestions, like this:
But in VS2017 Community, this feature is gone. Is there any option to turn it on? Or it's totally removed? Why?

It is disabled by default, you need to enable it in VS2017.
From here:
Add using/Imports for types in reference assemblies/NuGet packages –
if you type an unrecognized type, we will search for it in your
reference assemblies and on NuGet.org and offer a quick fix to add the
using/Imports. This feature is off by default; to enable it go to
Tools > Options > Text Editor > [C#/Basic] > Advanced > Suggest usings
for types in reference assemblies and Suggest usings for types in
NuGet packages. Enabling the latter option will download 10 MB of a
NuGet index on your machine and it will take several seconds to
complete (this will not affect your workflow in VS, but it does means
you cannot immediately use the feature once enabling it).

Related

Visual Studio 2017: References are mentioned not being built while they are already built

I'm working with Visual Studio 2017, enterprise version. I'm working on a C# project, depending on several NuGet packages.
One of my references is mentioned being missing (there's a yellow triangle above the icon in the solution explorer). When I double-click on it, in order to see its contents in the object browser, I get following error message:
This project cannot be viewed in the object browser because it is unavailable or not yet built.
Please ensure that the project is available and built.
You might think: "just restore the package (it's a NuGet package) and off you go", but the problem is that the message makes no sense:
In another project, I am using the exact same NuGet package as a reference, there everything is fine, and when I do a file/directory compare between that other project and my current one, WinMerge mentions both being equal. (Not only WinMerge, I also did a checksum comparison)
So my question is: what's the source of Visual Studio's This project cannot be viewed in the object browser because it is unavailable or not yet built. error message? What's the source of the yellow triangle in Visual Studio's solution explorer (for NuGet packages)?
Edit (added: Visual Studio version)
For your information, I'm working with Visual Studio enterprise 2017, version 15.9.36.
In the meantime I've found a workaround: I remove the references from the project and add them again, and it seems to work. Apparently there's some instability in Visual Studio reference handling.

Correct way to consume Home Grown Nuget Packages with Visual Studio

I'm currently working on a home grown .NET Core project. A developer in another division has created a NuGet package that has a lot of core functionalities. I was instructed that I should consume the package in my project to allow for shared code. I was sent the 2 files.
HomeGrownNuget1.nupkg
HomeGrownNuget1.symbols.nupkg
so in Visual Studio I went into Manage Nuget Packages for Solution -> Added a new Package source and pointed it to the local file where I stored the 2 files.
Then I browsed to the NuGet package and installed it.
However, when I run the program, I still cannot step into the logic in the NuGet package.
What is the proper way to get this to work?
If you want to debug a nuget package, there are some things that you (the consumer) should do and some things that the publisher should do. Guidance taken from this.
Publish the nuget package with symbols
dotnet pack [PROJECT].csproj --include-symbols --include-source
Setup debugger under Go to Tools -> Options -> Debugger -> General
Uncheck “Enable Just My Code (Managed only)”.
Uncheck “Enable .NET Framework source stepping”. Yes, it is misleading, but if you don't, then Visual Studio will ignore your custom server order (see further on).
Check “Enable source server support”.
Uncheck “Require source files to exactly match the original version”
Go to Tools -> Options -> Debugger -> Symbols.
Select a folder for the local symbol/source cache.
Add symbol servers under “Symbol file (.pdb) locations”. Pay attention to the correct order, because some servers may contain symbols for the same binaries: with or without sources.

Visual studio 2019 auto removed nuget packages after debug

Every time I add any nuget package to my .net core application, it stays for a bit but it seems like after I start a debug and end it, the nuget package removed automatically from Visual studio project.
Is any thing changes in visual studio 2019?
After searching on internet I found solution on this developer community Website.
Close VS2019
Delete the ".vs" folder
Open VS2019, add the NuGet package
Save all
I suspect "Save all" after adding a NuGet package might be key here.
You should see: In the NuGet.Config file, DisabledPackageSources tag shows you the sources which are currently disabled, so if you want to make them be active, add the sources under the ActivePackageSource. Anyway, since it works well now after you edit the DisabledPackageSources, at least, we make sure that it would be related to the NuGet.Configfile.

Visual Studio 2015 Add Publish Version Number

In previous VS versions adding publish version is easy. Just need to go to the project properties -> Publish and specify the publish number as shown in the below figure.
But this is the project properties window from the Visual Studio 2015.
Here I can't find any location to specify the publish version as I did on previous VS versions. So have they dropped this functionality to add publish version numbers or have they moved it to another place??
Try This!
Its free!
https://marketplace.visualstudio.com/items?itemName=PrecisionInfinity.AutomaticVersions
Usage:
To configure Automatic Versions, go to the Tools Menu -> Automatic Versions Settings
Each time you build your project, the versioning will automatically change.
To use the "On Demand" version options, right click on the project and choose "Build New Version"
Hope this helps!
Microsoft deprecated add-ins in Visual Studio 2015 so build number increment add-in is no longer working.
Your possible replacement is VsIncrementer (link)

Visual Studio 2013 dosen't recognize anything

I opened my WinRT (I'm using MVVMLight) project in Visual Studio 2013 this morning, and found out that all kind of types even system ones are not recognized saying Cannot resolve symbol 'bool' for example, note that the solution builds, executes and works all fine !
C# :
Even XAML :
I tried many things, closed and reopened the solution, cleared Resharper caches, I even restarted Visual Studio and the PC, but still the same problem, any solution to this problem ?
Update 1 : I tried to Suspend/Resume Resharper from Tools>Options and even delete files from AppData\Local\JetBrains\ReSharper\v8.0\SolutionCaches, and now Visual Studio causes errors too :
Update 2 : I uninstalled/re-installed visual studio, and I still have the same problems
If you have any Xamarin extensions for Visual Studio installed, it is a root of the problem. There are some compatibility problems.
As a possible workaround, you may try a workaround, mentioned in this ticket:
Select 'true' for 'Use msbuild to obtain project references' in
Project Properties (Click on project name in Solution Explorer | Hit
F4) for each project in the solution.
At least, it works for me.
If you can build the solution, but ReSharper marks your code in red - you can write the request here and you will likely get a help.
If you can't build your project then it is not ReSharper's problem. Then we need to find out why your build is broken.
It seems that your project to assembly references are broken.
To understand what's happening here with references during the build, go to Tools -> Options -> Projects and Solutions -> Build/Debug and set the verbosity to diagnostic. Then try to build your project and investigate the output windows in VS (or you can use MSBuild.exe from the command line instead). What you need to find in this large text block is "Resolve Assembly references" or "Expand SDK references" task. These tasks should obtain the valid paths to the assemblies your project depends on. Later on csc.exe should be executed with all these paths as parameters.
You can check whether the paths are correct, do they indicate to the existing binaries or not.
You can also create a new WinRT project template and check if it can build. If it cannot even for the clean project template then it is obviously a system problem, I suppose your platform sdk's are corrupted.
Hope this will help.

Categories