Related
When I starts a new project (Blank App (C++/WinRT)) on Windows10 1909 # VS2019(up to date) its shows up a lot of errors as if the extension wasn't installed. But after trying to compile and run its works - so why do I get the errors and how can I solve this? screenshot
Edit: I have fond a solution for that. its turns out that the project was needed an additional include directory:
under the project properties->C/C++->General->[Additional Include Directory]
I added the winRT folder:
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\cppwinrt
screenshot2
and that's it now there's no errors (correction - after creating new project its still have the same errors)
edit2:
Update: I installed the last windows 10 SDK and was still getting the seam errors. Than I installed a package via cmd with the following command:
D:\vcpkg> vcpkg install cppwinrt:x86-windows
after this was done it seem to work now
edit3:
I'm sorry for the annoying newcomer questions...
its looks like I have another problem now with my project
in the packages.config file is says that the package is not declared with the following warning packages.config pic
thanks for any help in advance.
(edit4) I followed this thread:
nuget 'packages' element is not declared warning
and that's it, now all I have to do is to learn how to code :D
The 'standard' include paths for Visual C++ projects are the VC_IncludePath and WindowsSDK_IncludePath. The Windows SDK includes path already has all of the directories:
include\<10.0.build.0>\ucrt
include\<10.0.build.0>\shared
include\<10.0.build.0>\um
include\<10.0.build.0>\winrt
include\<10.0.build.0>\cppwinrt
"Blank App (C++/WinRT)" is not part of the standard VS 2019 template set. The name of the project in the screenshoot is "ConsoleApplication2", which would imply you created a Win32 console C++ project instead of a C++/WinRT project. Even still, you can reach the standard C++/WinRT headers from a Win32 console application since they are part of the standard path.
From the looks of the errors in your first screenshot, it appears you are using a generated C++/WinRT rather than the one in the Windows 10 SDK. With VS 2019, you must add the NuGet package Microsoft.Windows.CppWinRT to your project to get the MSBuild rules needed to build with the C++/WinRT VSIX installed, so that's likely a problem here. See VS Marketplace
I've installed the newly released version of Visual Studio 2017 and started a fresh ASP.NET Core project targeting .NET Core.
Out of the box, I'm getting the
The type or namespace name 'System' could not be found (are you
missing a using directive or an assembly reference?)
error. Any idea what's causing this and how to fix it?
Also, looks like there are problems with NuGet packages as well:
I also tried dotnet restore on the project through the command line and got the following error:
P.S. Kind of disheartening that you get an error in a fresh new project in the latest version of Visual Studio 2017!
UPDATE:
SDK version is v 1.0.1 -- see below:
UPDATE 2:
This is very strange. Looks like the original problem was due to NuGet package source pointing to a folder under Visual Studio 2015 folder. I unchecked it and left only nuget.org. With that my project seemed to have restored all the packages and when I started the project it loads up the standard ASP.NET page. But if I open startup.cs file, I get red squigglies all over the place but if I run the project, it works fine. What's going on here?
UPDATE 3:
I closed the project and VS 2017. I then restarted VS 2017 and opened the project and now it seems to be fine. And I'm not referencing the .NETStandard library 1.6.1 and everything seems to be working fine now.
I had the same issue in my Visual studio 2017 .Net Core application. I closed the Visual studio and re-open fixed everything.
Came across the same issue today. I had an old nuget source that no longer existed. So I went into Tools > Nuget Packet Manager and un-checked the wrong one. Hit "Ok", and then rebuilt the project, and it works great now. It seems like you stumbled onto it, but also wanted to verify that it fixed my issue, and it does.
I had the same problem, first when converting a VS2015 net core mvc web project to 2017 and then when trying to create a new core web application in 2017.
Went to Tools|NuGet Package Manager|Package Manager Settings - checked 'Allow NuGet to download missing packages' and 'Automatically check for missing packages during build in VS' and then clicked 'Clear All NuGet Cache(s)'.
Then re-built the solution - it found and loaded all the required packages and ran OK.
May not work for all cases but simple and worth a try.
Multiple closing and reopening of VS2017 fixed it for me.
I had the same issue, the solution for me was to clear the NuGet cache. Tools > NuGet Package Manager > Package Manager Settings > Clear All NuGet Cache(s)
Check the version .NET Command Line Tools in CMD, just type dotnet --info. If version is 1.0.0, then try to install latest version .NET Core SDK from here.
Find the broken project and right click, Unload, right click, Re-load. Fastest fix for me.
If you get the problem while using the CLI, try doing nuget restore instead of dotnet restore as that sometimes pulls down packages that the dotnet CLI seems to miss.
I have had the same issue with Visual Studio 2019 and .NET Core SDK 2.2.
These steps solved the problem:
Close the Visual Studio
Open the Visual Studio as Administrator
Open the Solution
Right click on Solution -> Restore NuGet Packages
I've tried all answers above. For me works only removal and adding the reference again described in the following steps:
Open 'References' under the project.
Right click on 'System' reference.
Click on 'Remove'.
Right click on 'References'.
Click 'Add Reference...'.
From right menu choose an 'Assemblies',
In a search field type 'System'.
Choose 'System' from the list.
Click 'Add' button.
IMPORTANT: Restart the Visual Studio.
'System' reference you can replace with any you need.
Try adding the following line above the other references in the csproj file
<Reference Include="netstandard" />
For me the problem was caused by my project having a custom IntermediateOutputPath. For some reason, if project_name.csproj.nuget.g.targets is not in obj subfolder of project folder, the error occurs.
Using default IntermediateOutputPath or keeping a shadow copy of project_name.csproj.nuget.g.targets in fake obj folder solves the problem for me.
This issue seems to be triggered by a myriad of reasons. Mine was caused by cloning directly from VSTS using Git Bash, my project directory had spaces in it. Git Bash changed those spaces in the path to %20. It was throwing off all the references in my project. So for anyone who tried everything else and are at their wits end, make sure %20 is not in the path.
So, I have cloned the repository from github and started getting this error.
It was my project uploaded from another machine. I later realized that I have used the materialdesign packages in my project.
I have uninstalled and reinstalled these packages and it fixed my issue.
Had the same problem. Uninstalled Application Insights from my projects using the nuget package manager. I'm not looking at that yet, I just wanted core and unit tests. Problem solved.
I also had the same problem.
The is no SDK folder under the Dependencies one. Therefore, no Microsoft.NetCore.App libraries !
To solve this problem, in Nuget manager window, install any nuget which depends on .NetCoreApp (you can install for example Microsoft.AspNetCore or BundlerMinifier.Core from the Microsoft Visual Studio Offline Packages source).
The SDK will be restored by the same time.
Once it is back, you can uninstall the previously added nuget. The SDK will remain in place.
Not quite sure in which order vs 2017 trying to resolve packages.
But my situation was following. In my VS2015 I had configured local and 3rd party source for nuget packages, newly installed version of 2017 loaded them too.
https://api.nuget.org/v3/index.json was first in list.
But vs2017 throwed an error that it can't restore .net core libraries from my another local repo.
After I unchecked all of them except https://api.nuget.org/v3/index.json, it had started to working normally.
I had this problem too, but not right now, this steps solved my problem: Choose Project -> Properties from the menu bar. In the Project properties window, under Configuration Properties -> General, make sure that Common Language Runtime Support is set to Common Language Runtime Support (/clr)
Simply opening the NuGet package manager and then the Visual Studio settings related to it - without changing anything - merely looking around, and when I closed out, the problem was gone.
This seems to be an intermittent issue that can come and go for no obvious reason.
None of the answers here worked for me so I'm posting what did work.
My errors were mostly the same as the original poster but I also had:
Error loading meta data for 'Microsoft.Extensions.FileProviders.Embedded.2.0.1'
hexadecimal value 0x1C invalid character
Every time I attempted to download a different nuget package or restore old packages I would see this error. I also saw the other errors such as:
type or namespace system could not be found
What worked for me:
opened the filepath that the error said the bad metadata was in, which for me was C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.extensions.fileproviders.embedded\2.0.1
Then, I put the contents of that folder into another folder I named "hiding".
Then, I went back to the nuget package manager and tried to install a package, hoping to have the SDK restored. IOt worked successfully, and all my other errors were gone as well, and the fresh new project runs as it should!
The problem for me occurred when running my Visual Studio as Admin with a separate user-- I had created a Git Repo with the source files in the user documents of my normal account. When I created a new solution in that folder the above errors occurred. Try creating your project in a different place and see if the error still occurs.
I was facing the same issue when I created a new project (.net Core 2.2) in VS2019.In my case there was an Azure package which was creating the problem.I uninstalled it and the project started working fine.
Run mentioned below command to uninstall the package.
Uninstall-Package Microsoft.VisualStudio.Azure.Containers.Tools.Targets -Version 1.7.10
I had the same problem. I cloned a github project and this error came. So I deleted the cloned project and then I cloned the project again and it worked fine.
I have a build server build on Teamcity.
I'm trying to build a package using it, but I get an error.
The target "Package" does not exist in the project
I googled about this issue and found out I need to install Web Deploy. So I did. I've installed Web Deploy 3.5, but the error is still present. I've even did a reset.
This was top result on DuckDuckGo for me, so I feel this is an appropriate place to share Troy Hunt's wisdom. My "ProjectFile" was a Solution file. Solution files do not support the "Package" Target directly. My Build scripts (written in Cake in this case) were attempting to package the solution instead of the applicable projects.
I'm trying to configure Visual Studio 2012 to allow me to step into ASP.NET MVC 4.0 source code. (System.Web.Mvc.dll). I've followed SymbolSource's recommended configuration but when I try to load the symbols, Visual Studio can't locate them.
Recommended configuration
To configure Visual Studio for symbol/server
use, follow these instructions:
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. We recommend the following setup:
http://referencesource.microsoft.com/symbols
http://srv.symbolsource.org/pdb/Public or the authenticated variant
(see above)
http://srv.symbolsource.org/pdb/MyGet or the authenticated
variant (see above) (other symbol servers with sources)
http://msdl.microsoft.com/download/symbols (other symbol servers
without sources)
I am aware that the source code is available on CodePlex, however I'm specifically interested in stepping into the code using a symbol server instead of having to unreference Mvc from the GAC and reference a locally built assembly.
Has anyone had success doing this with MVC 4.0?
Just add a symbol server that serves more then just major releases.
Try this one, contains most minor builds.
http://srv.symbolsource.org/pdb/Public
Verify:
Run VS as administrator.
Check that something have been downloaded to your symbol cache directory.
Goto select only specified modules.
Add "System.Web.Mvc.dll"
Set a break point in your code. Start debug.
When break point hits rightclick in callstack on any mvc.dll row. Verify that symbols are loaded.
if loaded, try dubbleclick on one callstack row to open mvc source.
Get back with where you get in trouble.
I will make some refinements to Luke Gumbley's anwser.
Microsoft tries to make a developer's life easier. Whenever it release an MVC version installer, there should also be a Source to download. So people can use the source to explore what is installed by the Installer, as well as to debug the MVC.
Back to the way of downloading the MVC debug info. Your Visual Studio (I use 2010) will never try to download MVC PDB files from the aforementioned servers if you have MVC4 installed on your system. In this case, your Visual Studio will use the MVC from your GAC when you run debugger.
I have tried the way suggested by Luke Gumbley. However, once you uninstall MVC, your MVC project will not be loaded, and you cannot create a new MVC project since the Template is gone. So please don't unistall MVC. If you do so, you still need to reinstall it. This wastes time.
What you really need to do is exit your Visual Studio, run command
gacutil /u System.Web.Mvc
Then go to C:\Windows\Microsoft.NET\assembly\GAC_MSIL, remove or rename the offending System.Web.Mvc folder. After this, lanuch your Visual Studio, and fetch the MVC package from NuGet.
I can't answer on your question directly and provide you URL with symbols (.pdb) for System.Web.Mvc.dll for ASP.NET MVC 4.0, but probably I can help you to solve the problem in another way.
As well known (see here for example) Microsoft provide the current source code of .NET on http://aspnetwebstack.codeplex.com/. In the post it's described how to use the Nightly version of ASP.NET (the current developer state of the code). If you didn't used Git before you can have problems with downloading RTM version of ASP.NET 4.5 (with ASP.NET MVC 4.0) which you could prefer to use instead of Nightly version. Nevertheless the downloading of the full source code of RTM version is easy enough. You need just to know that Git allows to save copy of the code in branches or tagged versions. In the way you can get access (and download it) to some previous versions of the full code. The link for example provide you jQuery 1.8.2 instead of another link get you the latest developer version which can be unstable. So to download the source code of RTM version you just need to choose "v2-rtm" branch and then click on "Download":
You can use the link to select "v2-rtm" branch directly.
I can repeat that it's not exactly what you asked and I know that compiling of ASP.NET source code could be also a little tricky, but I decided do write the information. If somebody would suggest you the better solution it would be interesting for me too.
I had exactly the same issue (correct version but no symbols), but after a day or so of trying everything I've been able to get it working. These are catch-all instructions that worked for me, they may contain unnecessary steps:
Sign up for SymbolSource and follow the VS instructions using the
authenticated URL form
Uninstall all versions of MVC with add/remove programs
Remove MVC assembly from the GAC (the question is about modifying
MVC but the GAC answer is good)
Remove and then reinstall the MVC 4 reference to your project with
NuGet
Start debugging, open the modules window, and cross your fingers
that ‘Symbols loaded’ is next to System.Web.MVC when it appears.
(sprinkle in restarts as you see fit, for me the key final step was reinstalling the NuGet reference)
My theory is that as the GAC library is used at runtime in preference to the local reference, the symbols are not found when they are searched for. By removing MVC from the GAC and then reinstalling the NuGet reference, it seems the local reference is used and the symbols are found. It's counterintuitive as the System.Web.MVC.dll files are binary-equivalent between NuGet and the GAC, although they are dated differently.
I'm not totally convinced though as I tried to do the same thing for Razor and that didn't work.
Let me start with that ReSharper provides a handy dialog to step in the code at any time:
So you get the following code screen if you drill to the source code:
But I became curious to accomplish this by hand. I started with proper pdb configuration:
After that I got the following error:
Next I copied the C:\Users\Andrew\AppData\Local\Temp\SymbolCache\MicrosoftPublicSymbols\System.Web.pdb\CA49C4332DE847FA967F58AFF370B70E1\System.Web.pdb to C:\Users\Andrew\AppData\Local\Temp\SymbolCache\System.Web.pdb (to match the lookup path). After that i encountered this:
And it turned out that the mismatching builds are only good for browsing the source, not debugging. (Current machine has VS2012 RC, hence MVC libraries are not RTM). If they match, you'll the the source.
I still don't know why doesn't the lookup path adjust to symbol configuration. Hope this helps.
I just solved this same problem.
The problem is that the dll stored in the GAC does not correspond exactly to the published pdbs on symbolsource.org. The one on symbolsource corresponds apparently to the latest version available through Nuget, and the one in the GAC must the one installed with .NET Framework 4.5. (.Net uses whatever is on the GAC before attemting to use anything local to your proyect, you can see this, when debuggin, go the Debug->Windows->Modules, there the System.Web.Mvc.dll is the one from GAC according to its path)
What I did was to include in the GAC the System.Web.Mvc.dll on the package folder of my solution, the one downloaded through Nuget. This you can do by using gacutil on a VS Command Prompt (run the VS Cmd as admin).
You can check on the same Modules Windows, right clicking on the System.Web.Mvc.dll, and then on Symbol Load Information. With the "old" GAC dll you get a message like (part of it)
SYMSRV: http://srv.symbolsource.org/pdb/Public/System.Web.Mvc.pdb/1E540B87149F4031B9CDEACAD8D771231/System.Web.Mvc.pdb not found
Notice here the subfolder 1E540B87149F4031B9CDEACAD8D771231 (yours might be different)
After replacing the GAC dll for the one recently downloaded through Nuget, the message is
SYMSRV: System.Web.Mvc.pdb from http://srv.symbolsource.org/pdb/Public: 336067 bytes
http://srv.symbolsource.org/pdb/Public: Symbols downloaded from symbol server.
C:\Users\\AppData\Local\Temp\SymbolCache\System.Web.Mvc.pdb\68B2330E48624B6C9DE05BED1C8C320F1\System.Web.Mvc.pdb: Symbols loaded.
Notice the subfolder 68B2330E48624B6C9DE05BED1C8C320F1, which is the one that is searched for in symbolsource.org is the correctly found.
Hope this helps
There's some related info here: http://aspnetwebstack.codeplex.com/discussions/399312
And here: Debug into nightly build of ASP.NET MVC4 using Symbolserver
A similar question was asked and answered about a year ago, but was either a different issue (everything was in beta) or misdiagnosed. It's located here: MSbuild task fails because "Any CPU" solution is built out of order.
My issue is that I have a wix installer project, and after upgrading to Tfs2010 on monday, the build fails on linking because it can't find the build product of the Wpf application in the project. After some digging, it's because it hasn't been built yet. Building in Vs2010 works as normal. The wix project is set to depend on the Wpf project, and when viewing Project Build Order in the IDE, everything looks as normal.
The problem was originally encountered with only two platform definitions in the solution; x86 and x64. There are also two flavors, Debug and Release, and TFSBuild.proj is set to build all four combinations. There was no occurence of AnyCPU anywhere. Per the referenced question above, I tried changing the Wpf project to use AnyCPU so that it would be built first. At this point, the wix project used the exact configuration and the Wpf project used the flavor with AnyCPU. However, doing so didn't seem to change anything.
I'm using the Tfs2010 RTM, Vs2010 RTM, and the most recent version of Wix, which at the time of this writing is 3.5.1602.0, from 2010-04-02. Anyone else running into this?
2010-04-27: After a fair amount of digging, and reproducing on a cloned VM build machine, I believe I know what's going on and also what's failing, but I don't quite know how to fix it.
The situation is that this bug seems to exhibit symptoms based on pure luck-of-the-draw project ordering in the solution file. It appears as if the solution file will just blindly build the projects in the order they appear, relying on its ability to detect unbuilt references and build them on demand when needed.
In my particular solution file, my Wix project was ordered before my Wpf application project. This resulted in the Wix project being built first, and while the dependency on the Wpf project was detected correctly, the actual MSBuild task was skipped because of the undefined $(BuildProjectReferences) variable I mention a couple of comments down from the main post in this thread. With MSBuild verbosity still on diagnostic, BuildProjectReferences can be seen as undefined building the Wix project, and it can be seen defined as true upon building the Wpf project within the task to build the Wix project. Yet, when tested, it evaluates undefined again, the task is skipped, and the Wix build fails because it can't find the build output of the unbuilt Wpf project.
So bottom line: project dependency is skipped because of bad $(BuildProjectReferences) variable. Interestingly, this variable is present only in the Wix2010.targets file, and not in wix.targets; I guess that's why this is just showing up after I installed Tfs2010 and Vs2010.
The solution: How do I make sure that BuildProjectReferences is passed along correctly to the subsequent MSBuild tasks? Is there something special with variable scoping going on?
2010-09-14: A bug was opened for this issue in the WiX toolset: http://sourceforge.net/tracker/?func=detail&atid=642714&aid=2990231&group_id=105970 and fixed a while ago. Hopefully, this is no longer an issue. If so, please do open a new bug.
To address your comment directly, nothing in my solution has an AnyCPU configuration in their build files. I created the AnyCPU configurations only to test the solution suggested by the thread I linked to in my original post. After it didn't work, I removed the AnyCPU configurations again.
Furthermore, the projects are in the same solution file, however in separate solution folders (interface folder, installer folder) if that matters.
Interestingly enough, I was going to make a small sandbox example so that I could illustrate the problem I was having, however after creating my tiny sample solution, I couldn't get the error to reproduce. This makes me think that perhaps this is a result of using a team project that was upgraded from a Tfs2008 team project rather than one that was created fresh in Tfs2010. I may try branching my project into a new one to test this theory if I can't figure out why the test solution works.
p.s. also, I'm new to stackoverflow--why on earth are comments limited in length if the "answer your own question" workflow is intended only to provide concrete answers?
So I threw the build verbosity up to diagnostic and read through it today, and one line in particular stood out to me:
Task "MSBuild" skipped, due to false condition; ('#(_ProjectReferenceWithConfiguration)'!='' and '$(BuildingInsideVisualStudio)' != 'true' and '$(BuildProjectReferences)' == 'true' and '#(_MSBuildProjectReferenceExistent)' != '') was evaluated as ('..\WpfApp\WpfApp.csproj'!='' and '' != 'true' and '' == 'true' and '..\WpfApp\WpfApp.csproj' != '').
This was seen as my installer project was attempting to build my wpf project since the wpf project is referenced. In particular, for some reason $(BuildProjectReferences) is evaluating to '' when I'm fairly sure it should be 'true'.
However earlier in the log, at the beginning of the MSBuild task for the WpfApp project, I saw this:
Task "MSBuild" (TaskId:15)
...
Initial Properties:
...
BuildProjectReferences = true
So the property was indeed correct up until the beginning of the task, but then was apparently overwritten? I'm sort of unclear as to how these properties get set.
Its a bug, a bug, a bug. I don't know, who is responsible, but here's a working dirty filthy hack:
Open your .sln file in notepad.
Find your wix projects in the list of projects.
Cut them out, and paste them back after all other projects are listed.
Cry in the shower as you try to scrub the dirty off, only to emerge hours later, rubbed raw and still with the stench of filth clinging to you like corpse's skin.
Following Rob Mensching's edit of my original post, it seems that this has indeed been fixed in WiX 3.6.0917.0 at the latest.
I was seeing this problem (wix 3.7 not finding the dependent project output) in my local and TFS builds (for both VS2010 and VS2012).
I finally got around it by setting the msbuild property /m:1 to only use a single build process. I set /m to allow msbuild to figure out how many processes it could use to simultaneously build with.
I faced with a same problem today and find a solution like this:
Open your solution file on notepad the find your setup project and change postProject setting. This will tell msbuild this project should wait another project to build. I don't know why but it is not added by default.
Project("{GUID}") = "MyInstaller", "MyInstallerPath", "{Installer Project GUID}"
ProjectSection(ProjectDependencies) = postProject
{Prebuild Project GUID} = {Prebuild Project GUID}
EndProjectSection
EndProject
'Prebuild Project GUID' is the number on the right of the project that you want to install.
TFS uses a set of properties to control the names of the solutions and configurations to build ( iterate through ). For each combination of solution and configuration it then uses the project dependencies / build order to control the order of the projects getting built. It's possible that your EXE/DLL's are AnyCPU and that your WiX is x86 and that although the WiX has a dependency on the EXE/DLL the x86 is built before your AnyCPU. Or maybe they are even in different solutions so it's kind of hard to tell without looking at your source but that's basically how it works.
What we did is to first report the bug to wix and then we found your question.
We solved the problem on our side by saying that, by default, the wix project will build the references. We updated the file C:\Program Files\MSBuild\Microsoft\WiX\v3.5\wix2010.targets by setting <BuildProjectReferences>True</BuildProjectReferences> in the project which set the path. So, yes, we have done this manually ; we have reported the bug as well as our fix.