I'm trying to build ANTLR4 in Visual Studio (C++).
These are the errors:
Error trying to build
The unresolved externals are virtual destructors.
Why it is implemented like that? Pure virtual destructors must have a function body. How can I fix it and build ANTLR4?
Thanks in advance
Seems you used the latest code from Github. There is a pull request with fixes for the recent changes in the C++ target. Just download and apply this patch to make the code compiling. Currently there is no VS 2017 solution in the repo, so if you like you can create a pull request for that.
Although not related to destructors, there are other challenges if you haven't overcome them already. Getting ANTLR4 solutions to build in VS was a challenge. Other than several nuget installs, I remember having to do some manipulations to the project file as in:
<ItemGroup>
<Antlr4 Include="YOURGRAMMAR.g4">
<Generator>MSBuild:Compile</Generator>
<Listener>True</Listener>
<Visitor>True</Visitor>
</Antlr4>
</ItemGroup>
<ItemGroup>
<PackageReference Include="Antlr4" Version="4.5.3 YOUR VERSION" />
</ItemGroup>
And after all that I still don't have syntax highlighting in the .g4 grammar files. But the change above at least set up the build actions and let the background ANTLR classes rebuild when necessary.
Related
The scenario is:
1. Created a NEW solution
2. ENABLED download missing packages
3. Add projects to solution that already exists and depends on nuget packages
4. Building the solution generates an error:
... The missing file is <solution folder>\.nuget\NuGet.targets.
Why? Have missing something?
I'm using Visual Studio 2017 Pro on Windows 10
All my searches answer about the scenario where create a new solution and adds a new project that depends on nuget package, that's ok, but when have an existing project, nothing.
<solution folder>\.nuget\NuGet.targets is a file that NuGet's Visual Studio extension used to add in Visual Studio 2010, 2012 and 2013 when you right click on the solution and select "Enable NuGet Package Restore". It would then add an import in all of your project files to import the targets file. I was recently investigating a customer issue and as part of that investigation I found it made the following changes. Near the top of the csproj, it adds something like this:
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
<RestorePackages>true</RestorePackages>
and near the end of the csproj it adds somthing like this:
<Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
So, the problem is that you're creating a new solution, but using existing project files that have been modified in this way. One option is to edit your csrpoj files and remove these changes. Another option is to create new projects, in addition to the new solution, and then copy all your code and content files.
The only disadvantage is if you build on a CI server and use packages.config, your build script needs to run nuget.exe restore, whereas projects that use NuGet.targets could just build the solution and msbuild would execute nuget restore as needed. One advantage of no longer using NuGet.targets is that restoring the whole solution is faster than restoring project by project. Visual Studio automatically restores packages on build, even in VS2010, VS2012 and VS2013, so personally I discourage the use of using this feature, even if you use those old versions of Visual Studio. The benefit of reducing your build script by one step is not worth the issues it brings, in my opinion.
I'm using .NET Core and am creating a unit test.
To do this, I'm running "dotnet new nunit -n tests" to create a project with the first class to test another project.
The problem is: I can run the simple code created with "dotnet test", but I can't code because I'm receiving 'could not be found NUnit' error.
PS.: I'm using Visual Studio Code (last version).
My .csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<IsPackable>false</IsPackable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="nunit" Version="3.11.0" />
<PackageReference Include="NUnit3TestAdapter" Version="3.11.0" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.9.0" />
</ItemGroup>
</Project>
The error:
The type or namespace name 'NUnit' could not be found (are you missing a using directive or an assembly reference?)
I ran into this issue too and was perplexed by it. It turns out the problem is with the solution, not the dotnet new nunit project that was created.
The solution is auto-including the sub directory and attempting to build it as source. The directory can be excluded by right clicking the new test project in the solution and selecting "Exclude from Project". Rebuild and the errors go away.
I solved the problem using Visual Studio 2017 (not Visual Studio Code). It is better to architect a Microsoft solution.
EDIT: If you are using Visual Studio (complete version) you can see better the solution, projects and references.
If you are using Visual Studio Code and include new class or files, the reference is not added in you project file (.csproj) automatic. Maybe have another way to do that, but in the moment, I just use the complete version.
I'm part of a project where we use packages.config files for NuGet packages in Visual Studioe and then include each package dependency through the Import statement in our project files.
This works fine if you always want the packages, but we have some conditional packages that we'd like to exclude if the developer doesn't need/want it. I found the PackageReference tag, that would make the dependency much cleaner and would let us include the packages conditionally.
It seems to be fully supported in C# projects, but I can't figure out if it's supported for C++ projects or not.
I have tried deleting all of our packages.config files and replacing all references with PackageReference tags, but the PackageReference tag doesn't seem to be picked up by the package manager. I've gone through all the "migration tools" that I could find for Visual Studio too, with no luck.
Is it possible to use it for C++ projects? If not, is there a workaround that lets me exclude certain packages conditionally?
I'm using Visual Studio Professional 15.6.7.
Is it possible to use it for C++ projects?
At this moment, PackageReference is not yet supported for C++ projects. NuGet team is evaluating it to support for future releases. You might had made it work through some hacks but if you create a new c++ project and tries to install this package as PackageReference, it won't allow you. So I recommend you to continue using packages.config for your c++ projects and libraries.
Besides, you can add your request or vote for this feature on the Visual Studio UserVoice site: Use PackageReference in vcxproj. When there are enough communities vote and add comments for this feedback, the product team member will take this feedback seriously.
If not, is there a workaround that lets me exclude certain packages conditionally?
You can include the conditional references in the custom targets file and deploy the dlls in the tools folder of the package so they are not added as references by Nuget automatically.
certified: NuGet update and conditional references
Hope this helps.
While not supported, it IS possible to use PackageReference with C++ projects.
If you check the comments at https://developercommunity.visualstudio.com/t/use-packagereference-in-vcxproj/351636, there are a couple examples on how to enable this.
Note, the Visual Studio experience may degrade, but building with MSBuild (command line) has had no issues.
Note, we currently use PackageReference for VCXPROJ projects in ReactNativeWindows.
Being an unsupported feature, a couple hacks are required for Visual Studio compatibility, but all in all it works.
https://github.com/microsoft/react-native-windows
To summarize the other answers and provide some more recent information:
PackageReference is not officially supported in C++ projects, as it's not fully integrated with NuGet and Visual Studio, but:
MSBuild supports PackageReference, and Visual Studio 16.9 and later (this is 2019) have some integration implemented as well.
The full steps are described in a comment of the Make the PackageReference support general purpose for all languages PR, but basically:
above the project folder, create Directory.Build.props file with the following content:
<Project>
<Import Project="$(MSBuildProjectExtensionsPath)$(MSBuildProjectFile).*.props" />
</Project>
and Directory.Build.targets file with the following content:
<Project>
<Import Project="$(MSBuildProjectExtensionsPath)$(MSBuildProjectFile).*.targets" />
</Project>
in the project file add the following in the Project node:
<ItemGroup>
<ProjectCapability Include="PackageReferences" />
</ItemGroup>
and
<PropertyGroup>
<NuGetTargetMoniker Condition="'$(NuGetTargetMoniker)' == ''">native,Version=v0.0</NuGetTargetMoniker>
</PropertyGroup>
(or similar moniker)
Reload the project.
The above will make MSBuild and Package Manager work, with some caveats, e.g. you have to "Save All" after modifying packages through the UI, package references are not shown in the References node in the Solution Explorer, etc.
Note that Augustin Popa, which is PM for the Visual C++ team, gives an explanation why updating projects to the partially supported PackageReference may not be a good idea, because they have other plans for the future:
Our concern there is that if developers do the work to migrate to C++ PackageReference, they would later realize that we don't intend to provide ongoing support and want them to move to something else. I expect that would be a frustrating experience.
The "something else" he's talking about is probably a better integration with vcpkg, as discussed in his comment to the Use PackageReference in vcxproj feature request for Visual Studio:
From our side, we have to consider the needs of a very large user base with diverse requirements, which include support for CMake projects, installing packages for non-Windows platforms, and providing a better story for acquiring libraries that are actually compatible with the executable they attach to and with each other (achieved with vcpkg today). NuGet is not designed to handle these scenarios[...]
And still, even dev teams inside Microsoft are using the PackageReference approach, as seen in this comment for the same feature request:
We have made this work in React Native Windows via the following Pull Request.
As it’s been mentioned, MSBuild can handle this case for C++ (VCXPROJ) projects.
First-class support in the Visual Studio IDE would be highly beneficial for existing projects wanting to drop the traditional NuGet.exe/pakcages.config mechanism but can’t afford to rewrite the whole project to adjust to VCPKG.
At the very least, there is a drive space benefit to using PackageReference, so it’s not only about aesthetics.
When load my .NET Frameowrk 4.6.2 solution in Visual Studio 2017, it gives me the following warning:
Severity Code Description Project File Line Suppression State
Warning Your project is not referencing the ".NETFramework,Version=v4.6.2" framework. Add a reference to ".NETFramework,Version=v4.6.2" in the "frameworks" section of your project.json, and then re-run NuGet restore.
Another:
Warning IDE0006 Error encountered while loading the project. Some project features, such as full solution analysis for the failed project and projects that depend on it, have been disabled. BigData 1 Active
However, loading in visual studio 2015 is totally fine with the exactly same solution files and structures.
Why is this and how I can solve it?
BTW, from what I read, in the latest updates, project.json is merged back to .csproj, why here it's still recommending something on project.json
I had this show up as an error when building shortly after migrating a solution from vs2015 to 2017, and then also doing some git restructuring. As it turns out, I think git was actually the culprit.
Regardless, manually deleting the bin & obj folders in the affected projects solved it for me. (Clean alone wasn't cutting it.)
Are you sure, you installed all needed packages for your project? It could be a not installed feature. Go in the launcher to modify and check, are there all dependencies installed?
I am using Visual Studio 15 Preview 3
When I create a new project (ASP.Net 5 "Empty" project) and press build all it fails to build. I get the following errors.
Severity Code Description Project File Line Suppression State
Error MSB4063 The "VsTsc" task could not be initialized with its input parameters. WebApplication3 C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0\TypeScript\Microsoft.TypeScript.targets 247
Error MSB4064 The "OutputLogFile" parameter is not supported by the "VsTsc" task. Verify the parameter exists on the task, and it is a settable public instance property. WebApplication3 C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0\TypeScript\Microsoft.TypeScript.targets 261
Any suggestions please. I have added no code, just created the project and pressed build.
If you check out the Output window contents after the build has failed, it should show the targets file path like this one:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\TypeScript\Microsoft.TypeScript.targets
Go ahead and remove the OutputLogFile attribute from the VsTsc element. This should make the build go through.
Downgrading "Microsoft.TypeScript.MSBuild" from version 2.0.6 to 1.8.11 removed the Compilation Errors.
I had a similar issue. As it turns out the VsTsc task does support OutputLogFile. When I installed the newer TypeScript nuget packages (Microsoft.TypeScript.Compiler and Microsoft.TypeScript.MSBuild) then it adds Microsoft.TypeScript.targets to the .csproj but neglects to remove the previous lines. Nuget will add lines similar to
<Import Project="..\packages\Microsoft.TypeScript.MSBuild.2.1.4\build\Microsoft.TypeScript.MSBuild.props" Condition="Exists('..\packages\Microsoft.TypeScript.MSBuild.2.1.4\build\Microsoft.TypeScript.MSBuild.props')" />
<Import Project="..\packages\Microsoft.TypeScript.MSBuild.2.1.4\build\Microsoft.TypeScript.MSBuild.targets" Condition="Exists('..\packages\Microsoft.TypeScript.MSBuild.2.1.4\build\Microsoft.TypeScript.MSBuild.targets')" />
You have to manually removed the two lines pointing to :
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props')" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />
The same errors were observed after installing Visual Studio Preview. Visual Studio 2015 Community addition Update 3 installed on the same computer also started getting the same errors, on a number of different Typescript solutions. I could build the same solutions on an old computer 'Visual Studio 2015 Community addition Update 1'. I then uninstall Visual Studio Preview. Errors still occurred on Visual Studio 2015 Community addition Update 3. Also then uninstalled and reinstalled community addition and the problem was resolved, and could build the project. I thought this solution may help others with the problem solving a more elegant solution I do not have the reputation points to make a comment (where this belongs).
I was having the same issue with VS2015 Community and downloading the latest version of TypeScript (Version 2.1.5 posted 1/11/17) at https://www.microsoft.com/en-us/download/details.aspx?id=48593 did the trick for me.
I had the same problem. TypeScript tools in VisualStudio 2015 and TypeScript packages attached to project had different versions that is why build failed with "The "VsTsc" task could not be initialized with its input parameters". I reinstalled TypeScript tools for VisualStudio 2015 (get older vertion) it solved my problem.
I had a similar problem.
For me the solution was:
Remove "Microsoft.TypeScript.Compiler" package
Remove "Microsoft.TypeScript.MSBuild" package
from installed packages.