Configure ESLint with TypeScript in Visual Studio 2019 - visual-studio

I am trying to configure ESLint in Visual Studio 2019, I enabled ESLint in Options and I have installed ESLint 7.4.0 in node_modules inside my project, which should cause Visual Studio to use that version according to this document. But this causes a single not so helpful error.
When running eslint . in the command line from the same directory as the .eslintrc.yml file it works and errors and warnings about my code are reported.
When viewing a .js, .ts or .tsx file in Visual Studio it reports the following error internal-error: (ESLint) Unexpected token { at the first character of the file. No other errors are reported (where the command line does report errors). Visual Studio does report the usual intellisense TypeScript errors in these files.
The following is my .eslintrc.yml file.
---
parser: "#typescript-eslint/parser" # Specifies the ESLint parser
parserOptions:
ecmaFeatures:
jsx: true # Allows for the parsing of JSX
settings:
react:
version: detect # Tells eslint-plugin-react to automatically detect the version of React to use
extends:
- plugin:react/recommended # Uses the recommended rules from #eslint-plugin-react
- plugin:react-hooks/recommended # Uses the recommended rules from #eslint-plugin-react-hooks
- plugin:#typescript-eslint/recommended # Uses the recommended rules from the #typescript-eslint/eslint-plugin
Is there a way to see what Visual Studio is executing and what causes this error?
I tried running devenv.exe /log, but this logged nothing interesting, only that something was done with eslint. As you can see below.
821 Begin export of category 'TypeScript_EsLint' ({d5d56c12-87c4-46f2-894f-3a75ee781f48}) from package 'Microsoft.VisualStudio.LanguageServices.TypeScript.TypeScriptPackage, Microsoft.VisualStudio.LanguageServices.TypeScript, Version=16.0.0.0, Culture=neutral' ({2FFE45C4-5C73-493C-B187-F2E955FF875E}). 3095452 KB of virtual memory currently available. Profile manager 2020/08/19 08:11:21.001
822 End export of category 'TypeScript_EsLint' ({d5d56c12-87c4-46f2-894f-3a75ee781f48}) from package 'Microsoft.VisualStudio.LanguageServices.TypeScript.TypeScriptPackage, Microsoft.VisualStudio.LanguageServices.TypeScript, Version=16.0.0.0, Culture=neutral' ({2FFE45C4-5C73-493C-B187-F2E955FF875E}). 3095452 KB of virtual memory currently available. Profile manager 2020/08/19 08:11:21.003

I had almost the exact same problem, and thanks to the article linked from the comment by #Qurben, I solved it by:
Downgrade to ESLint 6.8, since ESLint 7 requires Node.js 12, and older versions of Visual Studio 2019 run Node.js 8. This may not be necessary any longer.
Add parserOptions.tsconfigRootDir = __dirname to .eslintrc.js (as seen in this instruction. Note that this probably doesn't work in .eslintrc.yml or .eslintrc.json.

Related

Rosyln.SDK missing from Visual Studio layout

I'm creating an offline network installer for VS2019, combined with VS config export/import to mirror my VS install between two machines.
I've selected specific workflows to reduce the layout from 50->15ish GB but when trying to install I get:
I cannot for the life of me see where this comes from.
It is not listed in https://learn.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-professional?view=vs-2019
It is not included in my exported vsconfig file:
{ "version": "1.0", "components": [
"Microsoft.VisualStudio.Component.CoreEditor",
"Microsoft.VisualStudio.Workload.CoreEditor",
"Microsoft.NetCore.Component.Runtime.5.0",
"Microsoft.NetCore.Component.Runtime.3.1",
"Microsoft.NetCore.Component.SDK",
"Microsoft.VisualStudio.Component.NuGet",
"Microsoft.Net.Component.4.6.1.TargetingPack",
"Microsoft.VisualStudio.Component.Roslyn.Compiler",
"Microsoft.VisualStudio.Component.Roslyn.LanguageServices",
"Microsoft.VisualStudio.Component.FSharp",
"Microsoft.ComponentGroup.ClickOnce.Publish",
"Microsoft.NetCore.Component.DevelopmentTools",
"Microsoft.VisualStudio.Component.FSharp.WebTemplates",
"Microsoft.VisualStudio.ComponentGroup.WebToolsExtensions",
"Microsoft.VisualStudio.Component.DockerTools",
"Microsoft.NetCore.Component.Web",
"Microsoft.Net.Component.4.8.SDK",
"Microsoft.Net.Component.4.7.2.TargetingPack",
"Microsoft.Net.ComponentGroup.DevelopmentPrerequisites",
"Microsoft.VisualStudio.Component.TypeScript.4.3",
"Microsoft.VisualStudio.Component.JavaScript.TypeScript",
"Microsoft.VisualStudio.Component.JavaScript.Diagnostics",
"Microsoft.Component.MSBuild",
"Microsoft.VisualStudio.Component.TextTemplating",
"Component.Microsoft.VisualStudio.RazorExtension",
"Microsoft.VisualStudio.Component.IISExpress",
"Microsoft.VisualStudio.Component.SQL.ADAL",
"Microsoft.VisualStudio.Component.SQL.LocalDB.Runtime",
"Microsoft.VisualStudio.Component.Common.Azure.Tools",
"Microsoft.VisualStudio.Component.SQL.CLR",
"Microsoft.VisualStudio.Component.MSODBC.SQL",
"Microsoft.VisualStudio.Component.MSSQL.CMDLnUtils",
"Microsoft.VisualStudio.Component.ManagedDesktop.Core",
"Microsoft.Net.Component.4.5.2.TargetingPack",
"Microsoft.Net.Component.4.5.TargetingPack",
"Microsoft.VisualStudio.Component.SQL.SSDT",
"Microsoft.VisualStudio.Component.SQL.DataSources",
"Component.Microsoft.Web.LibraryManager",
"Component.Microsoft.WebTools.BrowserLink.WebLivePreview",
"Microsoft.VisualStudio.ComponentGroup.Web",
"Microsoft.VisualStudio.Component.Web",
"Microsoft.Net.Component.4.TargetingPack",
"Microsoft.Net.Component.4.5.1.TargetingPack",
"Microsoft.Net.Component.4.6.TargetingPack",
"Microsoft.Net.ComponentGroup.TargetingPacks.Common",
"Component.Microsoft.VisualStudio.Web.AzureFunctions",
"Microsoft.VisualStudio.ComponentGroup.AzureFunctions",
"Microsoft.VisualStudio.Component.Azure.Compute.Emulator",
"Microsoft.VisualStudio.Component.Azure.Storage.Emulator",
"Microsoft.VisualStudio.Component.Azure.ClientLibs",
"Microsoft.VisualStudio.Component.Azure.AuthoringTools",
"Microsoft.VisualStudio.Component.CloudExplorer",
"Microsoft.VisualStudio.ComponentGroup.Web.CloudTools",
"Microsoft.VisualStudio.Component.DiagnosticTools",
"Microsoft.VisualStudio.Component.EntityFramework",
"Microsoft.VisualStudio.Component.AppInsights.Tools",
"Microsoft.VisualStudio.Component.WebDeploy",
"Microsoft.VisualStudio.Component.Debugger.JustInTime",
"Component.Microsoft.VisualStudio.LiveShare",
"Microsoft.VisualStudio.Component.WslDebugging",
"Microsoft.VisualStudio.Component.IntelliCode",
"Microsoft.Net.Core.Component.SDK.2.1",
"Microsoft.Component.PythonTools",
"Microsoft.VisualStudio.Component.VC.CoreIde",
"Microsoft.VisualStudio.Component.Windows10SDK",
"Microsoft.VisualStudio.Component.VC.Tools.x86.x64",
"Microsoft.VisualStudio.Component.Graphics.Tools",
"Microsoft.VisualStudio.Component.VC.DiagnosticTools",
"Microsoft.VisualStudio.Component.Windows10SDK.19041",
"Microsoft.ComponentGroup.PythonTools.NativeDevelopment",
"Microsoft.Component.PythonTools.Miniconda",
"Microsoft.Component.PythonTools.Web",
"Component.CPython39.x64",
"Microsoft.VisualStudio.Workload.Python",
"Microsoft.VisualStudio.Component.Node.Tools",
"Microsoft.VisualStudio.Workload.Node",
"Microsoft.VisualStudio.Component.ManagedDesktop.Prerequisites",
"Microsoft.ComponentGroup.Blend",
"Microsoft.VisualStudio.ComponentGroup.MSIX.Packaging",
"Microsoft.VisualStudio.Workload.ManagedDesktop",
"Microsoft.VisualStudio.Component.VC.Redist.14.Latest",
"Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core",
"Microsoft.VisualStudio.ComponentGroup.WebToolsExtensions.CMake",
"Microsoft.VisualStudio.Component.VC.CMake.Project",
"Microsoft.VisualStudio.Component.VC.ATL",
"Microsoft.VisualStudio.Component.VC.TestAdapterForBoostTest",
"Microsoft.VisualStudio.Component.VC.TestAdapterForGoogleTest",
"Microsoft.VisualStudio.Component.VC.ATLMFC",
"Microsoft.VisualStudio.Component.VC.ASAN",
"Microsoft.VisualStudio.Component.Windows10SDK.18362",
"Microsoft.VisualStudio.Workload.NativeDesktop",
"Microsoft.Component.NetFX.Native",
"Microsoft.VisualStudio.ComponentGroup.UWP.NetCoreAndStandard",
"Microsoft.VisualStudio.Component.Graphics",
"Microsoft.VisualStudio.ComponentGroup.UWP.Xamarin",
"Microsoft.VisualStudio.ComponentGroup.UWP.Support",
"Microsoft.VisualStudio.Workload.Universal",
"Microsoft.Component.CodeAnalysis.SDK",
"Microsoft.VisualStudio.Workload.NetCoreTools",
"Microsoft.VisualStudio.Component.Git",
"Microsoft.NetCore.ComponentGroup.DevelopmentTools.2.1",
"Microsoft.NetCore.ComponentGroup.Web.2.1" ] }
I can see it exists in a full layout and doesn't in my custom layout but not which workflow it comes from. Or why it hasn't automatically been added, isn't this a core component?
When I try to --add Roslyn.SDK to my layout using the VS installer I get the error Error: The package 'Roslyn.SDK' is not recognized.
So where does it come from and how can I get it in a custom layout? Can I even hack it into my layout somehow?
How can I find which workflow/component to add to get this included?
I eventually found that Rosyln.SDK is used by several workloads, as a non-documented dependency. Such as:
Visual Studio extension development ID:
Microsoft.VisualStudio.Workload.VisualStudioExtension Description:
Create add-ons and extensions for Visual Studio, including new
commands, code analyzers and tool windows.
ADding this resolves the issues I have but leaves me thinking it should have been there already for C#/.Net development.

"The process cannot access the file 'Default.rd.xml' because it is being used by another process." on AppVeyor CI

I am doing some work on cordova-windows (https://github.com/apache/cordova-windows), which is using AppVeyor for testing on Windows. One of the things that was missing, were tests with Visual Studio 2017 (only VS2015 was used to test before). So I added those and it works like a charm - mostly.
Unfortunately we now have a very strange test failure:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/cordova-windows/build/1.0.458
Started
Creating Cordova Windows Project:
Path: testcreate 応用
Namespace: com.test.app
Name: 応用
Windows project created with cordova-windows#5.1.0-dev
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x64
Patching 10 in prebuild event...
Injected base.js reference to the www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.WinJS.2.0\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.Phone.WinJS.2.1\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\Upload\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_Test\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_x64_bundle.appxupload
Your package has been successfully created.
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x86
Patching 10 in prebuild event...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\q\q.js:155
throw e;
^
Error: C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe: Command failed with exit code 1
at ChildProcess.whenDone (C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\cordova-common\src\superspawn.js:169:23)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at maybeClose (internal/child_process.js:920:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:230:5)
The relevant part is this:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
This is not happening when I run the tests locally, meaning I can in no way reproduce what is going on here.
Any idea what process could block this Default.rd.xml file or build\windows\bld\PackageUploadLayout\?
How can I find out in a CI environment like AppVeyor?
Update:
Investigated a bit more by adding /clp:Verbosity=normal to the msbuild calls that are executed.
It runs a similar msbuild call 3 times (once per architecture). The first one succeeds, but during the second one the failure occurs. Makes sense as in the first iteration the folder doesn't exist yet, which it confirms with this output: Directory "build\windows\bld\PackageUploadLayout\" doesn't exist. Skipping..
The last output before the failure then is Removing directory "build\windows\bld\PackageUploadLayout\". which matches what we get in the error message. No indicator why the removing doesn't work though.
Super strange: With /clp:Verbosity=detailed added to the msbuild call, the build actually succeeds! My guess: Because the output takes time, whatever is having a lock on the folder or file releases it.
This is not exactly an answer, but rather investigation report. It is just not enough room comments to describe it. Here is what I did:
forked your repo
created AppVeyor project
added RDP
connected with RDP
installed procmon
added filter to monitor objects which path ends with bld\PackageUploadLayout\Properties\Default.rd.xml
run npm test manually from CMD
When the same error happened I see this:
I am not sure I understand why msbuild failed this way. I opened SHARING VIOLATION event, switched to process and see this:
What catches my eye is that msbuild version is 14. Should be 15 on Visual Studio 2017 image. We have version 14 installed for specific scenarios but default one is 15 (run where msbuild and you will see C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe). I am not sure where this path is set in your scripts, but I feel if you make it run correct msbuild version this may help.

How to overcome "Could not load type 'Microsoft.Cct.Services.Sqm.IWatSqmService'" without updating?

I'm getting the same error message as in this question: Could not load type 'Microsoft.Cct.Services.Sqm.IWatSqmService' Unfortunately, I cannot upgrade to Azure SDK 2.9, as the top answer there suggests.
Specifically, I get this error in a message box whenever I try to package my Azure Cloud Service project:
What's interesting is that I can start the same project in the emulator, which I would assume involves packaging it.
Things I've tried:
Ensuring that I only have version 2.8.2 of the emulator installed (I may have had 2.9 installed initially)
Reinstalling version 2.8.2 of the SDK
Manually copying the Windows Azure Tools from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0 to the v14.0 equivalent.
Ensuring that C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.8 exists
Reinstalling Visual Studio (so you know I'm desperate!)
And I've no idea what to try next. I can't work out which DLL is supposed to hold the Microsoft.VisualStudio.WindowsAzure.Services assembly, I can't find any references in any config files, and all the Google hits seem to point back to the SO question linked above.
What's going on? And how can I fix it?
In case I'm being an idiot, here's all the Azure-related things I've got installed:
Also (just in case it's relevant) I'm on Windows 7 SP1.
Update 17/01/16
Following some advice from the excellent Rest Azured Slack channel, I've tried using ProcMon and Fusion Log to diagnose this (spoiler: without success)
ProcMon filtered to that assembly returns nothing:
Fusion log (set to log everything) yields lots of entries like this:
* Assembly Binder Log Entry (17/01/2017 # 11:52:02) *
The operation was successful. Bind result: hr = 0x0. The operation
completed successfully.
Assembly manager loaded from:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll Running under
executable C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\IDE\devenv.exe
--- A detailed error log follows.
=== Pre-bind state information === LOG: DisplayName = Microsoft.VisualStudio.WindowsAzure.Services, Version=1.1.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/Microsoft Visual Studio
14.0/Common7/IDE/ LOG: Initial PrivatePath = NULL LOG: Dynamic Base = NULL LOG: Cache Base = NULL LOG: AppName = devenv.exe Calling assembly
: Microsoft.VisualStudio.WindowsAzure, Version=2.9.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
=== WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with
Assembly.Load(). WRN: No matching native image found. LOG: IL assembly
loaded from C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\IDE\Extensions\Microsoft\Windows Azure Tools\Microsoft.VisualStudio.WindowsAzure.Services.dll.
When I explore the DLL mentioned, I can find Microsoft.Cct.Services.Sqm, but it doesn't contain a type IWatSqlService:
This feels like it's the crux of the issue, but I've no idea what to do next. Presumably I'd need to replace the DLL with a version that does define IWatSqlService, but I'm not sure where I'd get one. Or, for that matter, why it would even be necessary.
Next stop is probably a full wipe of the machine.
I've had the same problem, and solved it by not using the Web Platform Installer.
Download all parts (Microsoft Azure SDK for .NET - 2.8.2) from the Microsoft site: https://www.microsoft.com/en-us/download/details.aspx?id=50041 and follow the instructions how to install them.
For anyone else with this problem. I ended up resolving this by nuking it from orbit. Fresh install of Windows, reinstall VS and the SDK.
Confusingly, you can also see this error when you add a new
<setting name="TODO" />
element to your *.csdef file but either:
forget to add the corresponding <setting name="TODO" value="TODO" /> element to every *.cscfg file, or
accidentally add a duplicate <setting name="TODO" value="TODO" /> element to any of the *.cscfg files.

F# Microsoft.ParallelArrays not defined

So I downloaded and installed Microsoft Accelerator v2 to use ParallelArrays. I have referenced it in my project but when I try and execute the code from the module in a script file I get:
"The namespace 'ParallelArrays' is not defined
I have followed the instructions on this post:
Microsoft Accelerator library with Visual Studio F#
I've added a reference to the managed version "Microsoft.Accelerator.dll" to my F# project and then added the native "Accelerator.dll" as an item in my solution and set it's 'Copy To Output Directory' to Copy Always.
Still getting the FSI error and inline error in my script file on the '#load ...' line, however the solution builds fine, and no error in the module file.
Any ideas on what I'm missing? I'm sure it's something stupid.
Thanks,
Justin
UPDATE
I tried mydogisbox's advice, which got rid of the error above, but now when I run the code in the .fsx file I get this error instead:
--> Referenced 'F:\Work\GitHub\qf-sharp\qf-sharp\bin\Debug\Microsoft.Accelerator.dll' (file may be locked by F# Interactive process)
[Loading F:\Work\GitHub\qf-sharp\qf-sharp\MonteCarloGPU.fs]
error FS0192: internal error: F:\Work\GitHub\qf-sharp\qf-sharp\Accelerator.dll: bad cli header, rva 0
UPDATE 2
So the bad header error has dissapeared, but now I get this instead:
Microsoft.ParallelArrays.AcceleratorException: Failure to create a DirectX 9 device.
at Microsoft.ParallelArrays.ParallelArrays.ThrowNativeAcceleratorException()
at Microsoft.ParallelArrays.DX9Target..ctor()
at <StartupCode$FSI_0002>.$FSI_0002_MonteCarloGPU.main#() in F:\Work\GitHub\qf- sharp\qf-sharp\MonteCarloGPU.fs:line 14
Stopped due to error
I found this thread on MSDN however the answers proposed as fixes on that thread barely even relate to the question.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/98600646-0345-4f62-a6c5-f03ac9c77179/ms-accelerator?forum=csharpgeneral
My Direct X version is 11, and I imagine that will suffice, however I tried installing DX9 however, it tells me that a newer version is detected therefore cant install.
There are special directives for referencing dlls from fsi. The #load directive loads the .fs file only. You need to use the #r directive to reference the file. You can either use the full path of the file or you can use #I to include the path to the file. More details here. Keep in mind that fsi is completely independent of your project, so all references in your project must be duplicated in fsi for it to access the same types.

Visual 2010 MFC new project doesn't build!

I just created a new project in Visual 2010. It is a multi-document MFC (static link) application with the HTML help option, Visual Studio 2008 style (with style changing option), that's about it.
Just after creation, I hit Build Solution and I get a lot build errors all in afxcomctl32.h. Errors like:
Error 1 error C2061: syntax error : identifier 'LPCWS' C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxcomctl32.h 426 1
On this line:
AFX_ISOLATIONAWARE_STATICLINK_FUNC(HWND ,CreateWindowExW,(DWORD dwExStyle,LPCWS TR lpClassName,LPCWSTR lpWindowName,DWORD dwStyle,int X,int Y,int nWidth,int nHeight,HWND hWndParent,HMENU hMenu,HINSTANCE hInstance,LPVOID lpParam),(dwExStyle,lpClassName,lpWindowName,dwStyle,X,Y,nWidth,nHeight,hWndParent,hMenu,hInstance,lpParam),NULL)
Same errors in Debug and Release.
My PC is Windows 7 Ultimate. What's the problem???
Best regards,
Downy
AFX_ISOLATIONAWARE_STATICLINK_FUNC(..., LPCWS TR lpClassName, ...)
That code got messed up, there is a space or tab inserted in LPCWSTR. Deleting it will fix the problem.
However, that changed the timestamp on the file as well, you may run into trouble when you install a future service pack. One thing to try is to rename the file, then run a Repair to get the original file back. Or copy it off another machine.

Resources