When I try to run a Node.js debugging session from Visual Code, the debugging console returns an error, saying that the bootloader.bundle.js could not be found. However, the bootloader.bundle.js file exists at the expected location, while the debug console specifies the folder incorrectly by substituting a UTF-8 character (letter č) with the replacement character (�). The snippet of the error message can be found below:
Error: Cannot find module 'c:/Users/xxxx xxxx�/AppData/Local/Programs/
Microsoft VS Code/resources/app/extensions/ms-vscode.js-debug/src/bootloader.bundle.js'
Can I somehow fix this in VS Code, perhaps by modifying the launch.json file in some way or some other settings?
Any help is appreciated!
EDIT:
I temporarily fixed the issue by reinstalling VS Code to another folder without that doesn't include diacritical characters. I'd like to to keep this question open, however, in case somebody knows of a way to fix this sort of problem (e.g. by by modifying some configuration files) that does not require either reinstalling or relying on a portable version of the app.
I have just dealt with the same issue. There have been Unicode characters in my folder's path and I got the same error "Cannot find module". Reasons are described in details here.
To fix it I have gone to File - Preferences - Settings and then entered "usePreview" and then I unchecked the option "Use the new in-preview JavaScript debugger for ..." under the section "Debug > JavaScript: Use Preview" and reloaded VS Code. The issue has gone.
Related
So I'm trying to use the direct app install feature of Windows 10 Creators Update to allow downloading a packaged modern app from the web. The key feature of it is that it will auto update your app by checking back to the same URL of the .appinstaller file.
https://new-file-explorer.firebaseapp.com/ (the page is entirely generated by Visual Studio, no modifications from me)
The problem is that when I click it I just get "Error in parsing the app package."
If I manually download the .msixbundle that's referenced in the .appinstaller file it will work! Yet App Installer itself can't "parse" this package?
Here's the weirdest part: if I use "Add-AppxPackage -Appinstaller" from Powershell and point it towards the .appinstaller URL it will completely work!
The other answers on here do not apply, since they were all related to running it on a local server (I tried it anyways).
I thought this was related to MIME types, but I have set the MIME types as stated in the documentation and yet it still doesn't work. I've verified that by using this URL MIME type checker. I'm at a loss to what is actually causing this.
Here is the .appinstaller file:
<?xml version="1.0" encoding="utf-8"?>
<AppInstaller Uri="https://new-file-explorer.firebaseapp.com/InstallNFE.appinstaller" Version="1.0.9.0" xmlns="http://schemas.microsoft.com/appx/appinstaller/2017/2">
<MainBundle Name="NewFileExplorer" Version="1.0.9.0" Publisher="CN=david" Uri="https://new-file-explorer.firebaseapp.com/InstallNFE_1.0.9.0_Test/InstallNFE_1.0.9.0_x86_x64.msixbundle" />
<UpdateSettings>
<OnLaunch HoursBetweenUpdateChecks="0" />
</UpdateSettings>
</AppInstaller>
Here's a link to the .msixbundle it appears to be incapable of parsing (as you can see, it works manually downloading it!)
Thought of putting the solution in case someone else is facing the issue. I also faced the same issue and was able to resolve myself. When opening the Windows 10 .appinstaller file from web, the error "Error in parsing the app package." occurs.
For me the cause was that the links provided in the HTML page index.html generated by Visual Studio was referring to some share location (as my installer location was a file share location) and the installer file was not there. The reason for this is that I didn't do the last step "Copy and Close" of publishing from VS (this step copies the installer from output location to installer location that you provided). Instead of "Copy and Close", I just clicked on another option "Close" and hence the issue.
Just an additional input as i also encountered this issue and spent a whole day of finding the fix.
Let me just copy a line from .appinstaller file of the original poster.
<MainBundle Name="NewFileExplorer" Version="1.0.9.0" Publisher="CN=david" Uri="https://new-file-explorer.firebaseapp.com/InstallNFE_1.0.9.0_Test/InstallNFE_1.0.9.0_x86_x64.msixbundle" />
In this line, it only specify as ".msixbundle" file but the actual file in local folder is ".msixbundle.zip".
After I removed ".zip" from the filename of the file, the issue is gone.
My website project has a few JavaScript library dependencies, and I am using the gulp-concat plugin in my gulpfile.js to bundle them as one library instead of including them separately:
gulp.src(['src/js/angular.min.js',
'src/js/angular-route.min.js',
'src/js/angular-sanitize.min.js',
'src/js/domador.min.js',
'src/js/megamark.min.js',
'src/js/woofmark.min.js'])
.pipe(concat('libs.js'))
.pipe(gulp.dest('dist/'));
A problem was introduced once I added the domador, megamark and woofmark libraries.
Although these libraries work perfectly fine if referenced in the HTML separately, bundling them introduces some illegal characters into my libs.js which breaks Chrome:
Uncaught SyntaxError: Unexpected token ILLEGAL
Dev Tools shows me that there are indeed three unexpected characters in-between where megamark.min.js finishes and woofmark.min.js starts:
But! When I look at libs.js in Visual Studio:
There seems to be some kind of 'hidden' characters in the mix which become 'unhidden' to Chrome and kill the script. I don't understand why they are there or why none of things I've tried to remedy it are working...
What I have tried:
Bundle everything except woofmark.min.js and include that separately. Yes, this works, but I want to bundle them all (and I want to understand what is happening)
Re-saved the files in Notepad as UTF-8 encoding. No effect.
Backspaced from half-way through the first keyword in woofmark.min.js, many more times than necessary, then re-typed the necessary characters. No effect.
Similar effort for the last few characters of megamark.min.js. No effect.
Any insight would be greatly appreciated!
Thanks to the information provided by vp_arth in the comments, I found the solution.
It seems that the woofmark.min.js file was encoded as "UTF-8 with signature", which is another way of saying that it has the invisible BOM marker which produced the illegal characters.
When sent separately by IIS it was being converted, but when concatenated in a bundle, the marker was being retained in the middle of the file, creating the illegal token.
To fix, I re-saved the file with a different encoding in Visual Studio:
File ->
Save src/js/woofmark.min.js As... ->
Save with Encoding... -> (button drop-down)
Select "Unicode (UTF-8 without signature) - Codepage 65001" from options.
Then, after re-running the gulp task, the full bundled lib.js works perfectly.
How to avoid the window "No source available" while stepping into debug mode on VS2010 SL5
In Tools, Options, Debug, General Page. Check if you have 'Enable .NET Framework source stepping' enabled, if it is enabled, disable.
I tried all the suggested fixes; Nothing worked for me.
I finally figured out the solution after several hours of trial & error iterations.
It turns out that the 'No Source Available' error is due to a stack-overflow within the VS debugger env.
The C/C++ code function that was supposed to be stepped-into (by VS debugger), was using a variable that was initialized to a stack array of a few MB in size. When I replaced this with a heap allocation, VS was successfully able to step into the code.
This worked for me.
Please note that in my case, the actual code (with the stack allocation) ran without a stack-overflow error within the debugger (if I skip the No source available error). It was just that VS's debugger's was not able to step-into a particular function sitting inside another C/CPP file, because of the internal stack overflow.
Hope this helps.
You can hit Shift+F11 to step out and it will complete whatever unavailable function it is in and stop at the next line (it may be unavailable as well, but continue to use Step Out until you get to code you want to examine.)
Regarding VS2019, a description for the issue is provided at MSDocs.
For the requisite vcruntime and ucrt source files, the problem can occur after importing from a previous VS version which has since been uninstalled.
To prevent VS from using the old directories, find the solution property pages and navigate to the Debug Source Files Dialog Box.
Click the tick button to check the entries where any invalid ones can be removed.
The vcruntime and ucrt source should always exist in the directories, and the path at the top of the Browse to find source code dialog should always show the correct path.
In my case, because of a venerable drive bug, it is given to prompt for the "D" drive instead of the "C" drive. Further, the provided path cannot be pasted over to refresh the view, so, if none the wiser, one has to use the dialog to navigate all the way up to the required location from the desktop or equivalent.
Here there is an extension for this issue:
http://erwinmayer.com/labs/visual-studio-2010-extension-disable-no-source-available-tab/
But in my own experience before finding this article (I was in page but I was trying to fix it myself without reading article) I have fixed this problem just by accepting a confirmation message saying something like "Selected source file is different from compiled assembly. Are you sure you want to use this file for debug?". But I can't remember exactly what I did to get this message. I think there was a linklabel which I clicked on "No source available" window and then confirmation message appeared and after confirm the problem ran away.
I am working on a new version of a firefox extension, but after releasing it, and incrementing the em:version in install.rdf and update.rdf, when I click "Find updates" Firefox reports that "No updates were found." When I run it with debugging on, the output in the console is actually identical to what I see when I don't put the update live.
It starts with RDFItemUpdater:checkForUpdates with all of the parameters, and returns with Addon Update Ended and status: 8.
I verified with McCoy tool that the extension is signed, and has the same Id as the old one, etc. I'm not sure what else to try. Any advice would be appreciated. This is with Firefox 3 (and the extension is marked as compatible with it... that didn't change).
Make sure your update.rdf file is being served with an appropriate Content-Type, i.e. text/rdf, text/xml or application/xml+rdf
If you've only recently changed update.rdf, maybe it's cached. Load it in the browser then Shift-Refresh.
here are some nice tips that helped me: https://developer.mozilla.org/en/Extension_Versioning,_Update_and_Compatibility
but, auto update function will not work if extension is marked "experimental".
I'm having a similar issue, and think it's due to an invalid rdf file. Did you check that yours parsed with this tool? http://www.w3.org/RDF/Validator/
There are lots of things to mess up, one of which is installing an extension from AMO and expecting it to update when you change your update.rdf :)
I was having the same problem. In my update.rdf, I had a wildcard in my minVersion attribute:
minVersion="3.0.*"
Removing the wildcard fixed the status 8:
minVersion="3.0"
The update works now (console shows status 1). This was using Firefox 3.0.18.
My guess is that status 8 means there was a problem understanding the contents of the file (not necessarily an RDF parsing problem). If your minVersion doesn't have a wildcard, maybe there's an invalid character hiding somewhere.
I've installed Visual Studio 15.9.0, Preview 3 and created a project using the new platform support for C++/winrt. The project runs fine until I set a breakpoint. When the break is hit VS tells me "You need to find debuggerutils.h to view the source for the current call stack frame" It tells me this file was originally at onecore\com\combase\inc\debuggerutils.h, though it doesn't tell me the path to onecore. Search can't find such a file. Does anyone know how to find that file or install it? I had just assumed that VS would automatically include debugging capability.
[Update] Appears it is not the setting of a breakpoint but a bug causing a break before that. But I'm still mystified by the error message.
Someone asked this question on github's WinObjC issues:
https://github.com/microsoft/WinObjC/issues/2931
From the discussion:
edvv commented on Nov 22, 2019
Ah, now I remember what this means: "This is a false message. What really happened is that your app silently terminated (maybe by a console abort(), i.e.: crashed ) and when the app failed to launch (aborted) the front end gave that message. You need to look at the Windows Console window in VS while in debug mode."