I'm currently having two projects with typescript 1.1 that are opened in visual studio 2013 with typescript 1.8 installed. VS asks to upgrade which I did but now I get the following error:
Unknown compiler option 'listemittedfiles'.
Anyone has had the same?
It seems inside the project we had this line hardcoded
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" />
That way even though it was upgraded to 1.8 it still tried to use w/e was installed in that folder.
(This is a very old project that needs maintenance...)
Next to that I've removed the hardcoded path in the Path system environment variables so that tsc.exe now points to the NPM version.
If the above answer doesn't work for you, I suggest to take a look to this other answer which addressed that same issue on Visual Studio 2015 Update 3 and above:
(to summarize it, installing TypeScript 2.0 from this official link might fix the messed-up MSBuild cfg and solve the issue).
Related
like title after upgrade, VS detect many error like this:
But the code build successfully.
I try to repair Visual Studio 2022 but this not solve the problem.
Any suggestions?
Thank you
This issue is caused not by the Visual Studio update from 17.2.5 to 17.2.6, but by the update from .NET SDK 6.0.301 to 6.0.302 (which is automatically done during the Visual Studio upgrade). Intellisense is still looking for the code analyzers in the old SDK directories.
To find this, you should actually not look at the errors, but at the warnings (seeing you have 56 warning, I guess you tend not to look at them. It's a very good habit to keep the number of warnings at 0).
Inbetween the warnings you should see something like:
Warning CS8034 Unable to load Analyzer assembly C:\Program Files\dotnet\sdk\6.0.301\Sdks\Microsoft.NET.Sdk\analyzers\Microsoft.CodeAnalysis.CSharp.NetAnalyzers.dll: Could not find a part of the path ‘C:\Program Files\dotnet\sdk\6.0.301\Sdks\Microsoft.NET.Sdk\analyzers\Microsoft.CodeAnalysis.CSharp.NetAnalyzers.dll’.
How I fixed it: by manually opening the properties (alt-enter) of each problematic project. If you do that, it automatically fixes the paths.
Hans Passant's fix (deleting all the obj directories) seems way simpler, and might be a good thing to do on any Visual Studio upgrade. (Note, only delete the build obj directories, not those of dependencies, like git/github/node-modules/etc)
edit: Note that there is a side-issue with .NET SDK 6.0.302, where source generators run twice, which breaks anything that relies on them, like the WPF- and WinUI community toolits.
edit2: Microsoft has notified that these issues should be solved with the next release/update.
Updating Microsoft.CodeAnalysis.Analyzers from the Package Manager Console removed the warnings for me.
NuGet\Install-Package Microsoft.CodeAnalysis.Analyzers -Version 3.3.3
See: https://www.nuget.org/packages/Microsoft.CodeAnalysis.Analyzers/#versions-body-tab
I'd like our developers to use one version of Visual Studio for all of our projects (where possible) - to that end, I've asked them to use VS2019 for some projects that were originally created in VS2010 and then migrated to VS2013.
A runtime behavior change occurred when running one of these old webforms applications in VS2019. I'm not sure why it's different since the dlls being used are the same and the compiled IL is the same for the method in question, but at the moment I don't really care about "fixing" it since it would require making code changes and regression testing the entire application; a path I'd like to avoid for the moment.
What I'd like to do is make sure VS2019 builds with the indicated tools so that we retain the old behavior. The project file is referencing tools version 12 (VS2013 is not installed), but when Visual Studio builds I see the following in the MSBuild output:
Project file contains ToolsVersion="12.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="Current". For more information, please see http://go.microsoft.com/fwlink/?LinkId=293424.
I installed MSBuild Tools 2013, but that didn't correct the issue before or after a restart. I also tried with tools version 15 and got the same error (VS2017 is installed).
MSBuild from the VS2019 dev command prompt worked, but I had to copy the 14.0 webapplication targets to a new folder named "16.0". I'm not sure why there is a 14.0 folder but no 12.0 or 15.0 folder without doing more searching online.
Is this a fool's errand, or am I missing something simple?
MSBuild from the VS2019 dev command prompt worked, but I had to copy
the 14.0 webapplication targets to a new folder named "16.0". I'm not
sure why there is a 14.0 folder but no 12.0 or 15.0 folder without
doing more searching online.
Update 1
This is just a prompt warning to ensure that you'd better use the related MSBuild version to build the project. It is designed as a reminder message.
But in fact, MSBuild does add backward compatibility feature.
The message is just a warning rather than an error and will not break the build process. And if it breaks the build process, it can prove that backward compatibility is not supported.
You can test it: use VS2019 to build a VS2017 or VS2015 projects and I am sure that it can built them successfully.
==============================================
Each version of VS creates a project that is built for the corresponding MSBuild version.
For example, in the project created in VS2010, its ToolsVersion="4.0", so when you use MSBuild from VS2010(msbuild v4.0), it will built without that warning.
VS2013-->ToolsVersion=12.0 , VS2015-->ToolsVersion=14.0 , VS2017-->ToolsVersion=15.0, VS2019--> ToolsVersion=Current
So when you build the project, you should try the related msbuild version to build them.
Although MSBuild supports backwards compatibility, the problem is always in the form of a warning, which has been troubling us during the project migration.
Solution
To solve it, you should use the related MSBuild to build the project with the corresponding ToolsVersion.
If you want to build them in VS2017, you should change ToolsVersion to 15.0 in every project's xxx.xxproj file.
If you want to build them in VS2019, you should change ToolsVersion to Current in every project's xxx.xxproj file.
More info, you can refer to my answer in this similar issue.
Today, I decided to migrate my ASP .NET MVC 5 project from bootstrap 3 to bootstrap 4 (the sass version).
After the migration, I got an error after the compilation of my project.
Error Build:Cannot find name 'Record'.
Error Build:Cannot find name 'undefined'.
How to solve this?
After some research, I found this link to have a better understanding of typescript and visual studio. If you want to improve your skills, you can go to this official page and have some readings.
The solution
You just have to update the typescript plugin for Visual studio. You can download the latest version here for visual studio 2015.
Here for visual studio 2017
Enjoy!
If, for some reason you are unable to update your Visual Studio with the updated TypeScript .exe file (company/business IT policy, non-admin account, etc...), you can try this solution:
Single-click on the "index.d.ts" file in Visual Studio Solution Explorer.
Look in the Properties panel, under "Build Action".
Switch it from "TypeScriptCompile" to "Content".
Now, you'll be able to build your project without these errors.
Update 2019
I have found another workaround/solution that hasn't had any noticeable effects and still allows me to compile without erroring on index.d.ts. Just comment line 68 in your index.d.ts file as such:
//[name: string]: (BaseModifier & Record<string, any>) | undefined;
For Visual Studio 2015:
I downloaded TypeScript, installed and restarted Visual Studio. While restarting it prompted me the TypeScript my solution uses is older than what is installed(2.9.2) and whether I want to update it to the supported version, I clicked Yes and that fixed the issue.
My guess is TypeScript 2.9.2 is for VS 2017 maybe.
I uninstalled jpopper.cs and went to the Web.config file and added these lines of code
<appSettings>
<add key="ValidationSettings:UnobtrusiveValidationMode" value="None" />
</appSettings>
to deal with that validation error.
Out of the box, for me it has been fixed by update VS 17 to latest version!!
open your project in visual studio 2017 and it will ask you to upgrade the typescript just press upgrade
OR
Upgrade your Typescript version
This morning I upgraded to VS 2017 15.3 and now am getting yellow triangles for most of my references. The project runs fine (build is good in CLI and VS and restore has been run multiple times) that I can tell (and even better on dotnetcore 2.0 actually) but these remain. Has anyone else had this happen or have a suggestion? Thanks.
Link to project.assets.json file --> https://www.dropbox.com/s/c85yuyjiu4pnget/project.assets?dl=0
Also issue of greyed out usings and red references although everything builds and runs fine.
Update: VisualStudio twitter account responded to me to note that this is a bug and they are working on a fix for the future on this....
I have two responses to my post:
1) The using issue noted with things greyed out was actually a ReSharper issue. If you upgrade to VS 2017 15.3 and use R# make sure you update it as well to 2017.2.
2) The Yellow triangles issue is being looked at by the Visual Studio team but honestly I believe it to be linked to warnings in the build that those references are being coerced to either lower dependencies (ie Newtonsoft at different levels) or previews. The quickly evolving .NET 2.0 world may have exacerbated this issue. Yellow triangles have traditionally meant missing but check your warnings to see if that is related and then review the dependency chain. I will update this answer once I hear back from VS team (shout out to them and Damian Edwards + Scott Hanselman for helping me with this on Twitter).
I was experiencing the yellow triangle on references issue after updating the projects in my (.NET 4.6.1) solution to the new .NET Standard .csproj format that comes with VS2017. The references I was getting warnings for were ProjectReference type (although it seemed to spill over into PackageReference for common packages in the projects in question).
I did not have any build warnings and there was nothing in the verbose build output to indicate what the cause could be.
I could follow all warnings back to a single project in my solution. I was able to solve by removing that project from my solution and then adding it back and re-adding only the necessary project references.
It seems the issue was related to unnecessary project references (or possibly circular) caused by the new transitive dependencies support. After removing the project and adding it back with only the minimum ProjectReferences and relying on transitive dependencies support to propagate the dependency, the warnings all disappeared.
This also solved an issue where the project in question was failing compilation during a command line msbuild initiated build on my CI server which only has VS2017 build tools installed (not the full IDE).
I had the same issue, some of the references were marked with the yellow triangle. However, I was able to build and run my project.
I managed to remove these warning by following steps from this answer:
.Net 2015 References with yellow triangle for Nuget packages on portable libraries
I turned on tracing for Visual Studio, I had next warnings in log files for all uncorrectly loaded references:
Encountered conflict between 'Reference:Microsoft.Win32.Primitives, Version=4.0.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL' and 'Reference:C:\Program Files (x86)\Visual Studio\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\Microsoft.Win32.Primitives.dll'. Choosing 'Reference:C:\Program Files (x86)\Visual Studio\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\Microsoft.Win32.Primitives.dll' because AssemblyVersion '4.0.3.0' is greater than '4.0.2.0'.
To be precise, I did next steps:
Removed error condition from my .csproj file
Removed <Private>true</Private> parameter for not-loaded references in .csproj file
Deleted not-loaded packages from \lib and \ref folders in corresponding MSBuild folder.
Deleted packages from \packages folder in solution.
Restored nuget packages.
I'm not sure all these steps are necessary, but it worked for me.
You could check my answer on relative topic here: https://stackoverflow.com/a/59704420/7969733
Just for documentation purpose for new person with this issue try
this and you will rememberme :D
If you go to: Tools > NuGet Administrator > Configurations. and you
have "Allow nuget...." and "automatically check...." cheked.
The only thing than you have to do is click con the button "Clear
All NuGet Cache(s)"
That's it, you don't have to edit manual thinks than can be dangerous,
believe me, I use to need to done some of the steps than describe here
a lot of time, and try more than 5 steps of the official Microsoft
documentation for that issue you could check it here:
https://learn.microsoft.com/nuget/consume-packages/package-restore#restore-packages-automatically-using-visual-studio
But just cleaning the cache solve all the problems
To "Clear All NuGet Cache(s)" in Visual Studio 2019
Tools->NuGet Package Manager->Package Manager Setting
Mismatched Windows SDK Version between the referencing project and the references will cause it. In the vcxproj file it is "<WindowsTargetPlatformVersion>SDK Version</WindowsTargetPlatformVersion>"
I was upgrading from VS2012 to VS2017. Everything was good, then I upgraded to a new version of libtomcrypt and libtommath. Rather than tweak my existing projects, I up-converted the projects from the distributions from VS2008 -> VS2012 -> VS2017. In the process, I picked up Windows SDK Version 10.0.17763.0 in both the new projects. However, all of the projects that referenced those were 8.1, and thus the warning.
I know that this was ready to solve it, and one of my answers was ready to say something about that, but, maybe some of you present the same error and none of this solution listed here solves the problem... I don't know why this problem comes with the global installation of .net 6, but, if you present this issue again, you need to go to
C:\Users\YourUsername.nuget
And delete all the content, don't be afraid, that's a cache generator than will be created again if is need it.
I had a similar issue with visual studio 2017. And discovered that, if when I changed the dependency settings of the package I wanted to install (from lowest dependency to highest) everything worked fine.
Today faced the same issue with an imported project.
FAILED ATTEMPTS: Tried updating nougat packages, checking improper imports and everything imaginable. No help.
SOLUTION: At last just tried building the solution and it worked!
PS: Try building the project first. If it does not work then go for solution hunting.
Visual Studio cannot resolve interface ng.IScope (and others from ng module).
I have added reference to angular.d.ts but it doesn't help.
What's interesting a rectangular typings are working fine - even without adding the reference.
I am using Visual Studio 2013 Update 4 with TypeScript 1.4. Anyone can help? I tried everything.
I am using visual studio 2013 update 4 with TypeScript 1.4. Anyone can help? I tried everything :/
Suspect its just an issue of an old version lingering around. Try where tsc and make sure you only see C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.4\.
I have added reference to angular.d.ts but it doesn't help. What's interesting a restangular typings are working fine - even without adding the reference.
Make sure you have it added to the visual studio project.
Any luck ?
I have the same problem, however, if you use the older version
angularjs.TypeScript.DefinitelyTyped version=0.9.6
(Nuget -> Install-Package angularjs.TypeScript.DefinitelyTyped -Version 0.9.6)
everything works fine and it understands the ng.IScope definition.
I don't see any structural difference between 3.1.3 and 0.9.6, so I don't understand why the older version works.