I'm trying to get antlr working in VS. I’ve not touched VS for a very long time. I've added the AntlrVSIX extension per the Antlr online docs, this created a sample calculator project for me but I can't compile it (I uninstalled and reinstalled AntlrVSIX but it made no difference to the following problem).
VS complains “The type or namespace name 'Antlr4' could not be found (are you missing a using directive or an assembly reference?)” and points to the line “using Antlr4.Runtime.Misc;” (and lots more similar).
If I look in menu Tools:NuGet Package Manager:Manage NuGetPackages for Solution… it clearly shows Antlr4.Runtime.Standard present and installed (showing version 4.8.0).
I guess I have to add a reference to this dll to my project so I I right click on References:Add Reference... in Solutions Explorer but I can’t find it in any list, however I search.
There is a Browse button which I assume I could use to link to the DLL directly, so I’ve searched the disk, found the dll and linked to that. This now works in that all those errors go away, but this can’t possibly be the right way.
So how do you add a reference to it properly, using References:Add Reference...? VS knows it’s there, it displays it, but doesn’t let it be referenced like that because it won’t show it within VS via References:Add Reference...
On your specific question, yes, you don't want to add a reference to the dll. Instead, you need to add a "<PackageReference>" in the csproj for these dependencies. All this lives in Nuget.org. So, in VS2019, right click on a project in the Solution Manager, then look for "Manage Nuget packages" to add Antlr4BuildTasks and Antlr4.Runtime.Standard.
Note, I've been updating the Antlrvsix extension, but haven't made a release for 2 months, longer than my usual schedule, because the next version has a huge number of changes. I will be cutting version 8 in a week. The template in VS2019 was removed because it is old and out of date. It uses an ancient version of the Antlr4BuildTasks. Instead, use the Antlr4BuildTasks.Templates v8.1 to create a C# project from scratch. Please follow the directions here. You don't need to download the Antlr tool kit, Java, or set any environmental variables. You also don't even need to use VS2019. You only need Net Core 3.1 and to install Antlr4BuildTasks.Templates. Then, type "mkdir foo; cd foo; dotnet new antlr; dotnet restore; dotnet build; dotnet run" at a command-line shell to create a C# application with Antlr4. Once you create the application, you can modify that to what you need. If you start from a Net Standard or Net Core project that doesn't have Antlr yet, you will need to add in the project reference for Antlr4.Runtime.Standard 4.8 and Antlr4BuildTasks 8.1, add in all grammars, and driver to set up and call the parser--harder to do, but it can be done through VS, or you can edit the CSPROJ file more easily and faster. The Antlr4BuildTasks looks at your CSPROJ file and will see that Antlr4.Runtime.Standard 4.8 is referenced, then will use the correct version of the Antlr JAR file to generate the parser and lexer. Any questions, let me know.
I suggest you using Antlr4.CodeGenerator NuGet package, it's gonna generated all necessary files (visitors, listeners) to work with your grammar in antlr. Check out my article for the details, there is a link to Github repo with the solution that works in VS 2019.
Related
I have created a very simple NuGet package from a .net framework visual studio Class Library project, where the class library source is in C#.
I used this command to create the nuget package:
nuget pack MyProject.csproj -symbols -Properties "Configuration=Debug" -suffix debug
Which creates, as I expect, two nuget package file, namely:
MyProject.1.0.0-debug.symbols.nupkg
MyProject.1.0.0-debug.nupkg
These packages are basically identical other than that the one with "symbols" includes the pdb files in the lib hierarchy and source files in the src folder.
Given the duplication, I rename the file MyProject.1.0.0-debug.symbols.nupkg as MyProject.1.0.0-debug.nupkg, which overwrites one of the files, no big deal there. I now have a conventionally named package with PDB and source files in it.
I deploy this to an internal file share feed with:
nuget add MyProject.1.0.0-debug.nupkg \\InternalShare\FeedFolder
In an entirely different project, and a different solution, I now consume that NuGet package in Visual Studio with the NuGet Package Manager. All works great. And the code works fine too, in my case I made a simple console app that uses a couple of classes in the package and I have demonstrated that it uses them correctly and without incident.
So far so good.
Now I set a breakpoint in the consuming code, and attempt to step into the source to debug the package. It seems to work OK, but actually, it isn't going into the source that was distributed with the package. It actually steps into the ORIGINAL source from the creation of the package, in a completely different and unrelated folder hierarchy on my machine.
OK. So now I recreate my simple console app on a separate computer that does not have the ORIGINAL source. And on that separate computer, which is on the internal network and hence has access to the file share, I consume the NuGet package and again, everything compiles and works fine.
When I try to step into the package source code in the visual studio debugger, however, it simply doesn't work. The debugger can't find the source code even though it is right there in the package folder. (The debugger offers to disassemble the code -- not so helpful).
This seems like it should be a common use case and desire for including symbols and source code in a nuget package, so I must be doing something silly such that the debugger can't find the source.
Various versions of things:
Visual Studio: Professional 2017 15.9.11
NuGet Package Manager installed in VS: 4.6.0
CLI NuGet version: 4.8.1.5435
Targetted .NET Framework for my sample code: 4.6.1
What is my mistake?
Many thanks in advance.
================== ADDED INFO 4/17/2019, 3:30pm Pacific =======================
This isn't quite as bad as I thought. When I try to go into the code and says it can't find it, I am given the opportunity to browse to the code, so I can browse to the package (assuming I know where it is!) and set the debugger loose and everything works fine. The nice thing is that Visual Studio seems to remember where I browsed to and knows to look there next time. Not sure of that mechanism.
AND.... If I go to my original computer (with the actual package source on it) if I change that initial source, like I am getting ready for the next package, the debugger (of course) realizes that the source has changed, and likewise prompts me to look for the proper source elsewhere.
Still, it would be great not to have to jump through hoops like that, so I would still appreciate any further insights.
Back in Feb'2019 it was working. Few things which are not mentioned here and I added to csproj file are
<DebugSymbols>true</DebugSymbols>
<EmbedAllSources>true</EmbedAllSources>
<DebugType>portable</DebugType>
I packaged with nuget and command used is:
nuget pack mynuget.nuspec -Symbols -SymbolPackageFormat snupkg
I was using VS 15.9.4 and nuget 4.9.3 at that time With this I could successfully debug nuget from network path . Not sure what changed in recent releases, its not working now.
Some fundamentals:
the debugger needs PDBs to enable debugging
a symbol package should contain PDBs (it is not merely a package with a different extension)
this symbol package should be published to a symbol repository that Visual Studio debugger can request symbols from
Next:
See this doc for creating and publishing symbols package to nuget.org (.snupkg)
Then, see this doc for configuring visual studio to for using NuGet.org as a symbol source (use this value when adding a symbol server https://symbols.nuget.org/download/symbols)
Previously, we used the project.json to setup our projects dependencies. The Asp.net Core team moved away from that and went back to using .csproj. However, when trying to type in the name of a package, it no longer auto-completes like it used to.
For instance, typing in the following line would show intellisense when I typed the . after Microsoft, providing me with the packages within that namespace.
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="1.1.2" PrivateAssets="All" />
How do I get this functionality back?
It's still there in a Editor Extension called "Project File Tools" which is a Microsoft Extension and I am pretty certain this should be installed by default, but on VS 15.3 Preview it didn't seem to be working (was installed, but I didn't had any other extensions there). Somewhere in between disabling/restarting/enabling it and/or installing the Web Essentials it started working again.
As for Ctrl+. doing a reverse package search, it's there too but disabled by default:
Go to Tools > Options > Text Editor > C# > Advanced (or hit Ctrl+Q and type "C# Adv" + Enter) and check "Suggest usings for types in NuGet packages".
If you already have a highlighted error before setting the changes you got to remove the piece of code and add it again before it gets recognized (read: it only applies for red-squiggles that happen after the change).
This will probably depend on which IDE you are using.
If you're using Visual Studio then you'd right click on dependencies or csproj then click "Manage Nuget Packages".
This will open a view where you can search for packages and install them.
If you're using Visual Studio Code, there are couple of plugins that'll help you search and add packages you're looking for.
https://marketplace.visualstudio.com/items?itemName=jmrog.vscode-nuget-package-manager
Lets you search package and add specific version.
I'm creating a Visual Studio Project Template and bundling it inside of a VS Extension. I need Projects created from the Template to reference ~20 NuGet packages.
Is it possible to have the references resolved from nuget.org rather than having to include all of the references inside the VSIX?
The NuGet documentation on Visual Studio Templates provides instructions on how to add packages inside the VSIX, but it requires the file be stored locally on disk and the .nupkg is bundles inside the vsix:
Add your nupkg files as custom extension content in your source.extension.vsixmanifest file. If you're using the 2.0 schema it should look like this:
<Asset Type="Moq.4.0.10827.nupkg" d:Source="File"
Path="Packages\Moq.4.0.10827.nupkg" d:VsixSubPath="Packages" />
Question already asked
I know a similar question was asked (Creating a Visual Studio Project Template that already includes a Nuget Package Reference?) and answered (not possible), but this was asked in 2011.
5 years later, is it still not possible?
Since there is still no Built-In functionality to Install/Upgrade packages from online Repo, here is a small workaround wich might help:
Prerequisites
First, install the NuGet.VisualStudio nuget package into your project.
You get that from here
When installed, the package will automatically set the Embed Interop Types property of the assembly reference to True. The reason it does so is to make your code resilient against version changes when users update to newer versions of NuGet.
For the same reason, you must NOT use any other types besides the above interfaces in your code. You must NOT reference any other NuGet assemblies either, including NuGet.Core.dll.
After setting up all that stuff, you can do the following in your RunFinished-Method:
var componentModel = (IComponentModel) Package.GetGlobalService(typeof(SComponentModel));
IVsPackageInstallerServices installerServices =
componentModel.GetService<IVsPackageInstallerServices>();
if (!installerServices.IsPackageInstalled(project, "Newtonsoft.Json")) {
var installer = componentModel.GetService<IVsPackageInstaller>();
installer.InstallPackage(
"All",
project,
"Newtonsoft.Json",
(System.Version) null,
false);
}
Note
That example shows based on Newtonsoft.Json how you can install a package.
For sure you can choose the projects targeting the installation. Also you can determine the Version to be installed.
It seems a bit uncomfortable, but unfortunately there is no other way around.
Usings
using Microsoft.VisualStudio.ComponentModelHost;
using Microsoft.VisualStudio.Shell;
using NuGet.VisualStudio;
Let me know if that helps!
Yes, you can create a nuget package and add those other packages as its dependencies. Then when you download that package it will get all its dependencies and add to your project.
I have installed the most current version of Sandcastle from NuGet (EWSoftware.SHFB version 2015.10.10.0), and the needed Reflection package (EWSoftware.SHFB.NETFramework version 4.6).
I read #Frank-Rem answer to Numid's question How to generate documentation using Sandcastle NuGet package (EWSoftware.SHFB)? and tried to add a new project to my solution. However, when I try to add a Sandcastle Documentation project I do not have the Documentation project type as an option.
I uninstalled the NuGet package and reinstalled it, thinking it may have been a buggy install. But the documentation project type is still not an option, even after shutting Visual Studio down and relaunching it.
I read through the readme.txt file and saw that I will need to add some property tags to the .shfbproj file when it gets generated. Beyond that, I don't see any other steps that I need to perform or packages to install in order to get the project type to show up. I have also gone to the GitHub project page and checked the Issues tab to make sure this isn’t a known issue they are working on.
I am using Visual Studio Ultimate 2013.
Are there additional steps I need to take to get the Sandcastle project type to show up in the Add New Project list?
Thank you for any ideas!
I was able to resolve the issue by running the Sandcastle Help File Builder Guided Installer. This identified missing components and installed them.
I was then able to follow the instructions from #frank-rem on adding the documentation project and documentation source to the new project.
Assuming that you already have a solution with a project, add a new project of type 'Documentation' to your solution.
Right-click Documentation Sources and add a source by selecting the csproj you wish to document.
Then just build.
Additional steps I took to get a finalized help doc: I found that Sandcastle had added several TODO items, which didn't show up in the Visual Studio task list. So I did a search on the solution for TODO and resolved them that way.
After that I followed the instructions on adding the namespace summaries provided by #davy-landman (in a comment to Davy Landman's answer) to clear up some missing flags.
This has actually changed in the latest version (currently 1.9.3.0) to Project Properties > Summaries > NameSpaceSummaries. – Ant Swift Jan 6 '12 at 9:44
When I add a reference to my dll in Visual Studio project, I am able to use it, but when I compile my code or try to run it, I get an are you missing a using directive or an assembly reference?_ Error. I am able to confirm that I have the right using statement for my namespace and I am able to confirm that the dll is correctly loaded.
Anyone have any idea what I may not have right in this?
Go to project settings and make sure that you are not compiling the project for a .net version that includes the text "client profile".
I had just had an issue precisely like this, even if this is an old question thought I would add my 2c on what fixed it as none of the other answers helped:
For whatever reason, when I built the solution top to bottom a certain dll was not getting updated and output that held changed code. So while my solution had no visible errors, when you attempted to build, it was still referencing the old dll and started complaining.
It was simply a case of directly re-building the offending project and after that it picked up the latest dll and built happily.
This seemed to be a freak accident as no configuration had changed between when it worked / when it didn't.
Sometimes, JUST REBUILD THE SOLUTION.
The location of the DLL is important.
If you add a reference on your local machine to a DLL that is outside of your Visual Studio solution, it isn't necessarily copied into your solution files (depends on the type of solution/project).
If this is your problem, then you need to either put the DLL in the same path on the other machine, or copy it into your solution so it gets deployed along with the solution files, and change the reference.
You can also handle this with build instructions, but that might be beyond your aspirations at the moment.
Most likely your dll is referencing another dll that the client project is not referencing and your dll code is exposing a type or an interface from the 3rd dll to the client code.
If you post the exaCt message, we'll be able to help better.
Are you using .net 4.0?
If yes, this dll is probably not compatible with .net 4.0
In my case, the main project (WinForm) was configured Framework Target: FW 4.0 "client profile". I change to FW 4.0 and work perfect!!.
At first time i was looking in the referenced projects and they were ok, but de main project doesn't. I hope this help. Thank you.
In my case this compilation error has gone after adding the reference to Microsoft BCL Build Components via "Manage NuGet packages" context menu on problem project.
Before: I had project Main (console application) referencing project A (class library).
Project A had dependency on Microsoft BCL Build Components.
After: I started refactoring where I picked out several classes to the separate project New. It also depended on A. But the compilation error occurred on project New as if there was no reference New -> A (although Visual Studio didn't highlight allegedly not found interfaces and classes listed in the error list of compilation).
So I checked project A's dependencies and found there Microsoft BCL Build Components.
After adding it to New's dependencies everything worked fine.
The most interesting thing is that Main did not contain this dependency and it didn't need it.
Hope this helps.
You just Have to check your namespace of that class file again...it will work