when restoring a locally created nuget package I receive the following error:
Failed to add reference to 'Microsoft.Data.SqlClient.SNI.x64'.
Please make sure that the file is accessible, and that it is a valid assembly or COM component
When I look at the nuget build I see the following
click to enlarge
The highlighted yellow "missing" dlls in the screenshot above do actually exist in the project.
I am using Visual Studio 2017 professional
Thanks for any help
Mark
Nuget package update - Microsoft.Data.SqlClient.SNI.x64
Please try the following steps:
1) close VS Instance, delete nuget.config file under C:\Users\xxx(current use account)\AppData\Roaming\NuGet.
2) delete .vs hidden folder under your solution folder, bin and obj folder then restart your project to test again.
3) Please try to create a new empty project in VS2019 and test whether you can install the package Microsoft.Data.SqlClient.
If you cannot install it, you should note that whether your VS or OS has broken. If the new project has no error, the issue is your project itself. You can try the above steps to troubleshoot the issue.
If the issue still persists in the new project,
You can try to repair VS or update VS to the latest version.
Also, try to update OS or use the System File Checker tool to repair missing or corrupted system files.
Besides, try another PC to test whether the issue persists.
Microsoft.Data.SqlClient.SNI.X64 or X32 files need to be removed from release folder before creating package.
Microsoft.Data.SqlClient.SNI.X64 will be added automatically while adding Microsoft.Data.SqlClient.
So, remove the dll before creating the package and then try installing it.
I've been working on a project with a coworker and we're using Visual Studio 2017 as IDE and also Git to push the versions to VS repository. We had a few problems and decided to start a new project in Visual Studio with the content we already had.
The weird thing is: when cloned the repository to my computer and synched, some of the references were lost. A yellow triangle appears next to the lost references icons in Solution Explorer, and it doesn't have a path set like the ones that work. Also, inside Source > Repos, the project folder has all files, including the ones that are missing. I tried deleting the project and cloning it again, tried to download only the .zip file and starting the project offline, and also running VS 2017 as administrator (it appears this solved similar problems for others before) and nothing worked. My coworker (who pushed the project to the repo in first place) can compile normally and is not facing this reference problem.
Has anyone ever experienced this issue?
We're using VSTS with a git repository, and this happens all the time, especially when pulling updated solutions. I find a clean and rebuild fixes the problem.
You can run in the Package Manager Console the following command to clean up the nugget packages:
Update-Package -reinstall -ProjectName XYZProjectName
or run it for the whole solution:
Update-Package -reinstall
In my case after a merge with the master branch, I had conflicts in the project file (.csproj). When resolving the issue VS2019 automatically had unloaded the project file where those conflicts were and I didn't notice. A check for that might save time for someone.
I once experienced it when I was having a Visual Studio 2015 project open and then pulling new git commits. The new project I was pulling was was set up for Visual Studio 2017 though.
So my VS 2015 was open and dsiplaying the now VS 2017 project. I believe it only contained one nuget package, however this was not downloaded correctly and instead the package was displayed as a missing file.
Maybe this is happening for you too?
Same problem in VSC 2021 version 1.63.
Solution - Removed project folder from workspace:
CTRL+Shift+P, search for and execute the
"Workspace: Remove Folder from Workspace" command.
Then reopened the project folder and was OK
I have read many of the answers on SO and NuGet (and the Internet in general, really), but I can't seem to overcome the problem I am having with NuGet package restore in Visual Studio 2015. I have the following scenarios.
Solution A Structure
--Project A
If I open and build Solution A I see the dialog box that shows the nuget package restore progress and the solution builds successfully.
Solution B Structure
--Project A
--Project B
However, assuming that I have never built Solution A (i.e. fresh pull from TFS), if I open and build Solution B I see the dialog box that shows the nuget package restore progress, but the build fails because Project A fails to build.
What appears to be happening is that that NuGet is restoring the packages for Project B, but not for Project A thus the build failure. To the point, if I look at the references for Project B all of the NuGet references have resolved, but the references for Project A are still broken.
A few points:
I have disabled source control integration for NuGet so I am not checking in the Packages folder.
Each project has its own packages.config file
The build order in Solution B is Project A then Project B
Thoughts would be greatly appreciated.
By default, NuGet creates the solution's packages folder in the solution root, and each project references its package DLLs to that "local" packages folder. In your example, if you open the .csproj file for Project A, you'll probably see that the reference path is something like ..\packages\[package name]\[etc].
So when you do a fresh pull from TFS and build solution B, Project A can't find its DLLs because c:\workspace\Solution A\packages doesn't exist yet (or whatever the absolute path is on your machine).
To correct this, use a shared package folder, created at c:\workspace\packages. To do this, you have to add an additional node to the NuGet.config in each solution (see https://docs.nuget.org/consume/nuget-config-file for details; I am also assuming you have a NuGet folder at c:\workspace\Solution A\.nuget):
<config>
<add key="repositorypath" value="..\..\packages" />
</config>
I used a relative path here, but you can use an absolute path as well, and the documentation says you can use %HOME% as well.
Do this, then restart Visual Studio. The next time you open the package manager, it should ask you if you want to restore missing packages, and assuming you click yes, it will put them in the new location. The last step is to edit the .csproj file and change all instances of ..\packages to ..\..\packages (or you can uninstall and reinstall the package, but I find editing the .csproj a lot faster).
To restore nuget packages do following steps:
Change target framework in project properties
Clean project
Set previous target framework
Rebuild project
I hope, it will help.
Taken from OPs question
howcheng's answer is generally correct with some caveats. After implementing the changes howcheng suggested, I was able to build all of my solutions locally using a central 'packages' folders that all projects look at, regardless of solution. The problem that I ran into though was that when I checked these changes in to TFS, my CI build kicked off and failed!
My CI Build Definition builds both Solution A and Solution B as part of the default XAML process template, not a .proj file. The errors that I was seeing seemed to indicate that Solution A was restoring its packages, but Solution B was not. If I logged onto the build server and opened Solution B in VS 2015 everything worked fine; after Googling for a couple of hours I came across this article which ended up leading me to my answer.
I am developing in Visual Studio 2015 but I am using TFS 2013 for source control and builds. Despite the fact that I have Visual Studio 2015 installed on the build server, MSBuild still references the version of NuGet that shipped with TFS 2013 and NOT with the version included with VS 2015. Once I ran nuget update -self from the TFS Tools directory my build worked correctly.
I use Visual Studio 2015 and azure sdk 2.7.1. I created azure web job. When I run deploy I get error:
The target "MSDeployPublish" does not exist in the project.
I created web job in Visual Studio 2013 - deploy is work. I compare the two projects(2015 and 2013) - in 2013 there is this code:
<Import Project="..\packages\Microsoft.Web.WebJobs.Publish.1.0.3\tools\webjobs.targets" Condition="Exists('..\packages\Microsoft.Web.WebJobs.Publish.1.0.3\tools\webjobs .targets')" />
I put this code in my project in 2015, but deploy is not working. I saw
this question, but it does not work for me.
Using VS2015, when installing the Microsoft.Web.WebJobs.Publish NuGet package I noticed in the package console that the install.ps1 powershell script threw an error due to lack of execute permissions. On inspection it appears this script was meant to add in an import reference within the .csproj of the project I was installing to. Adding the following line to my .csproj file did the trick and fixed the above error for me;
<Import Project="..\packages\Microsoft.Web.WebJobs.Publish.1.0.6\tools\webjobs.targets" Condition="Exists('..\packages\Microsoft.Web.WebJobs.Publish.1.0.6\tools\webjobs.targets')" />
Note: your package version might be different, in which case replace 1.0.6 with whatever version matches your installed package.
Note: Your solution setup may be different, in which case make sure your path to the ..\packages folder is correct.
Note: this issue occurs when you don't run VS with administrator rights.
I had to remove the Nuget, restart with administrator rights, and add it again to resolve the issue.
I was able to get this issue resolved simply by adding a reference to the above mentioned Microsoft.Web.WebJobs.Publish NuGet package. No additional modification of the .csproj file were necessary in my case. I'll assume that's because of improvements in the VS 2015 tooling since the question was first posted ;)
This works for me
Step 1: Run Visual studio as an administrator
Step 2: Make sure you have the import line (mentioned above in previous comments) in .csProj file
Step 3: Delete Webjob.Publish.Settings.JSON file (as it was showing an error) and Publishing profiles
Step 4: Deploy as Azure web job
I ran the visual studio 2015 with administrator rights. It is work for me.
Just wanted to let you know that simple package update did the trick for me.
I got this error in a project with a project.json for the nuget packages.
When I removed the project.json and used the packages.config everything worked fine.
Mind that I did set the ExecutionPolicy for Windows PowerShell before I tried this, (see solution of #Jon Crowell), this might be necesary too.
If anybody finds a way to solve this with a project.json please let me know!
I just downloaded Visual Studio Code and my Intellisense is not automatically working.
The two settings that control this seem to be set correctly:
"editor.quickSuggestions": true,
"editor.suggestOnTriggerCharacters": true,
I do get an Intellisense menu when i start typing and press "CTRL + Space", but this gives me a list of everything and not things specifically for my object.
What am i doing wrong?
If you have a workspace and for some reason have multiple folders you may need to 'help' omnisharp a bit. I initially had a big project and added a solution for it further on - ending up with TWO workspace folders (one to a startup project and one to the solution). After composing that setup I experienced only the first project to have intellisense working.
Solution to get intellisense working was to make sure omnisharp worked its way from the solution instead of the project:
Ctrl + Shift + p
Write "OmniSharp: Select Project" and press Enter.
Choose the solution workspace entry.
Inspiration gotten from 'swaner':
https://github.com/OmniSharp/omnisharp-vscode/issues/1889
Visual Studio Code's more advanced editing features (IntelliSense, refactoring tools, etc.) only work in C# files if you have a project.json file or *.sln file that VSCode is aware of. Open the folder (i.e. open the File menu and click Open Folder...) with the *.sln file or project.json and VSCode will attempt to find all project/solution files in the folder. If there are multiple projects, you may need to select one from the projects button on the right side of the status bar (bottom of the window).
From the VSCode website:
Selecting a project.json-file is opening a DNX-project and VSCode will load that project plus the referenced projects
Selecting a *.sln-file is opening a MSBuild-project. It will load the referenced *.csproj-projects and sibling or descendant project.json-files but no other project files that are referenced from the solution file.
Selecting a folder will make VSCode scan for *.sln and project.json files and VSCode will attempt to load them all.
If you are start your project with c#, then some time you haven't download extension.
Process by written
Ctrl + Shift + p.
Write "OmniSharp: Select Project" and press Enter.
Choose the solution workspace entry.
Then enable the c# extension for "OmniSharp : Project".
Process by image
Downgrading to 1.23.9 of the C# VS Code extension fixed the intellisense for me. So if nothing else is working for you, perhaps try installing an older version of the extension (doesn't necessarily have to be that exact one I mentioned). You can do this by selecting this option in VS Code:
As of the 0.5 version I have found that I need to close and re-open my working files to get some new intellisense information to start working for my own files. This usually happens after I have a file open that needs to use type information from another file I just created. Until I close and re-open them (within the editor) the intellisense doesn't always work.
Hopefully this is something that'll get fixed as the app matures.
Inorder to make the intelligence working, the Visual Studio Code extension OmniSharp should be there along with Mono. When you open a project/solution folder, the OmniSharp gets the project dependencies from either project.json or from the dotnet solution file (if the project/solution created with other versions of visual studio).
So, when you look at the omnisharp's output window after immediately opening the project/ solution folder, you may see the following lines
Starting OmniSharp server at 2017-9-18 09:26:44
Target: /Users/{username}/Source/{Your Solution Folder}/{Your Solution
file}.sln
OmniSharp server started wth Mono
Path: /Users/{username}/.vscode/extensions/ms-vscode.csharp-1.12.1/.omnisharp/run
PID: 5808
post that, you may see couple of lines coming up like below,
[info]: OmniSharp.MSBuild.MSBuildProjectSystem
Update project: {Your Project1 Name}
[info]: OmniSharp.MSBuild.MSBuildProjectSystem
Update project: {Your Project2 Name}
....
they mean that your projects are getting recognised by OmniSharp Extension.
If you get any error message informing you about timeout, please get into the settings of the Visual Studio Code, and add a configuration override like the one below:
"omnisharp.projectLoadTimeout": 200
I know it is too long to wait for 200 seconds. But don't worry, this won't stop you anymore working with project files. But, remember that the IntelliSense will be automatically available once all the projects in the folder are successfully loaded.
Feel free to extend the Timeout setting since it will help you getting intellisense even-though you are not getting it immediately.
Here is another link with the same solution: https://github.com/OmniSharp/omnisharp-vscode/issues/1585
Hope my information helps you! Enjoy your VSCode!
This case was for an existing project that was working fine before. Opened via the vs code "recent" history.
For dotnet core. I opened my project's *.csprog file, made no changes, and saved it via the vs code editor.
As soon as I saved, all of the intellisense stuff starting working again in my other files within that project.
Another troubleshooting strategy to try if none of the above works out is uninstalling Mono, which is unnecessary anyways if you're using .NET Core. I also experienced a sudden disappearance of Intellisense after pulling changes to one of our enterprise repos that included an upgrade from ASP.NET Core 2.0 to 2.1. Strangely, at the same time, Intellisense was working fine in another C# project repo running ASP.NET Core 2.2.
For the project in question, I was puzzled to see successful logs for each reboot of the Omnisharp server as well as perfectly clean builds and runs. The puzzlement increased as I compared these Omnisharp logs to those from the 2.2 project and found them effectively identical.
Upon uninstalling Mono, the one detail that changed is how Omnisharp started. Now it boots up from a shell script located at ~/.vscode/extensions/ms-vscode.csharp-1.19.0/.omnisharp/1.32.18/run. Previously, Mono itself was booting the server from the executable at ~/.vscode/extensions/ms-vscode.csharp-1.19.0/.omnisharp/1.32.18/omnisharp/Omnisharp.exe.
Other troubleshooting I attempted in this instance though to no avail:
dotnet clean / Deleting bin and obj directories
Updating launch.json to point at the proper /bin/Debug/netcoreapp2.1 build
directory
Wiping my local nuget cache
Restarting Omnisharp
Uninstalling and reinstalling VS Code, as well as bumping back a version from 1.33.1 as the breakage coincided oddly with the March 2019 update
Uninstalling and reinstalling the C# VS Code extension, as well as bumping back a version from 1.19.0 given other users' reports of said version interfering with Intellisense for certain projects*
Adding a global.json file at project root to override default utilization of latest .NET Core SDK (mine was 2.2.105) and run instead using 2.1.302 in concert with the project's version
Wiping/rebuilding the project .sln file
Specs: VS Code 1.33.1, C# Extension 1.19.0, MacOS High Sierra 10.13.6.
*NB: As it turns out, in another .NET Core 2.1 project with the same issues in VS Code as described above, uninstalling Mono alone did not fix things. I also did wind up needing to bump back the C# extension to v. 1.18.0 to recover Intellisense. Weird.
The issue I had was OmniSharp was an older version. I set the flag to update to latest version in Settings.json file. This ensures the extension is always the latest version.
"omnisharp.path": "latest"
And restarted VS code. That fixed it for me.
Simply reinstall the extension and restart the VSCode/PC.
I use Task Manager and kill the Visual Studio Code process, then restart Visual Studio Code, the intellisense shows and fixed.
I've had some good experiences in C# with this extension so far:
https://marketplace.visualstudio.com/items?itemName=jchannon.csharpextensions
This extension traverses up the folder tree to find the project.json or *.csproj and uses that as the parent folder to determine namespaces.
Try "Install Extension" from command Pallete - probably if C# intellisense is not there:
https://code.visualstudio.com/docs/customization/colorizer
if intellisense in not working for react js or javascript or node js this solution will help for windows
uninistall type script by typing npm uninstall -g typescript
install specific version of type script that is 3.3 by typing npm install -g typescript#3.3
add the typescript location in vscode by navigating to file > Preferences > settings > here search for edit in setting.json then add this path "typescript.tsdk": "/Users/yourusename/AppData/Roaming/npm/node_modules/typescript/lib"
settings.json should look someting like this
{
"editor.suggestSelection": "first",
"vsintellicode.modify.editor.suggestSelection":"automaticallyOverrodeDefaultValue",
"typescript.tsdk": "/Users/yourusername/AppData/Roaming/npm/node_modules/typescript/lib"
}
I was able to fix this by changing the Api Compatibility Level from .Net Standard 2.0 to .NT 4.x. You can find this setting on Project Settings / Player.
After that, intellisense started working again.
This is because of C# extension issue.
Reinstall the extension will work.
https://code.visualstudio.com/docs/editor/intellisense
https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csharp
I fixed this with a multiple project solution in .net5 / .net core 3.1 by
opening each project (not the sln folder) in VSCODE. This then prompts to add the resources/ .CSX? files to the project; enabling intellisense, per project. Finally close that window and reopen the solution folder and all works as expected.
See image
Add VSCode assets
Downgrading to 1.23.9 of C# for Visual Studio Code (powered by OmniSharp).
https://i.stack.imgur.com/VrdJl.png
After trying several things I looked at the OmniSharp logs only to realize that because I had two different sln files in my workspace. It had picked up the “other” one and thus wasn’t working. I deleted it, reopened vs code, and all is well again.
For me I had been working without internet for a long time. It had previously been working but then stopped. I closed+reopened VSCode with a stable wifi connection and the Output tab in VSCode popped up, displaying the the extensions were re-installing. After that it worked!
in my case , the extension wasn't enabled
I just had this happen (this being no code completion suggestions appearing). What resolved it for me was changing the VSCode Editor package in Unity to a previous version and then back to the current version.
For me, this was going from 1.2.0 to 1.1.3 and then back to 1.2.0. I believe removing and reinstalling 1.2.0 would have accomplished the same.
Window > Package Manager > Visual Studio Code Editor
I know this is probably the most obvious answer. But I had enough dealing with VS Code ridiculous bugs. You should be focusing on code, not the buggy IDE. Their documentation doesn't make it easy either to debug.
Steps for complete uninstallation:
Save your personalization files such as keybindings.json,
Just put it on GitHub or something so whenever you need have trouble with VS Code you simply just need to go to GitHub and copy-paste it.
Uninstall VS Code completely
When you uninstalled VS Code, it doesn't erase your extension files and some old settings. This is the cause of the re-installation ended up the same. Horrible move VS Code. For the list of the files that you must delete, you can check out this answer.
Go to their website and install the new one.
I hope this helps some people who are already had enough with the VS Code ridiculous bug.
In my case, the issue was not with VS Code settings. The error was due to a corrupted TEMP path configured in my PC's registry user profile environment settings.
I got this error from Help --> Toggle Developer Tools --> Console
The error was flagged in the console when I opened a new typescript file.
Unable to write file c:\Users\XXX\AppData\Local\Temp;C:\wamp64\bin\php\php5.6.25;C:\vufind-3.1.2\install.php\09cf49d8-af5b-42e9-8194-43f5b566be0f'
Obviously this path was corrupted. After updating the environment variables in registry settings, the VS code IntelliSense started working. Checking the console is a good start to find the root cause of this issue.
Earlier intellisense was working for Angular in VS-Code but for some reason (which I don't know) intellisense stopped working. I had extensions installed i.e. Angular Essentials and Angular Language Service etc. that were responsible for this intellisense and all that.
What I did?
I disabled the extensions, restarted VS Code and enabled them. It was all working fine as before.
If everything in VSCode is working ( No errors in output console, language server is working etc.) and built-in extensions are enabled. Still, if your IntelliSense is not working for normal .js files make sure variables are defined with a type identifier such as var d = new Date() or let d = new Date(). In my case, IntelliSense was not working for d = new Date() (No autocomplete for Date object 'd' APIs in this way) but started working fine when I specified a type before my variable names.
Download and install "Tool for Visual Studio 2019" as the C# extension under hood use the build tools: https://visualstudio.microsoft.com/downloads/
In my case, I had an extension installed (Explorer Exclude) to help me focus and hide certain files that I don't regularly work with within the Explorer.
I so happened to have disabled viewing *.sln, *.csproj and *.vsconfig files and folders, which apparently prevents VSCode from even knowing the file is there in the first place. Disabling these specific rules solved the problem instantly.
Took me ages to figure out... The more you know.
I solved it by uninstalling all SDK's (not sure if this is needed)
and installed 4.7.1 developer pack
win 10, vscode 1.63.2, unity 2020.3.25f1
I fixed this by installing .NET Framework 4.7.1 Developer Pack:
https://dotnet.microsoft.com/en-us/download/dotnet-framework/net471