We Keep Coding

ASP.NET Core Browser Link `Unable to get property 'files'`

In the Microsoft Virtual Academy course 'Introduction to ASP.NET Core (formerly ASP.NET 5)', video 3, at 39:00, they demonstrate how Browser Link can sync code selection between Edge's F12 tools and Visual Studio. I haven't been able to see the same functionality out of the box. I don't know if there's a setting, or something special to enable this. If there is, it wasn't shown in the course video, but then again the video is a couple months old. I've never seen this functionality before.
Browser Link is connected to Visual Studio from Edge, as can be seen in the Browser Link Dashboard in VS. That's all fine.
There is a console log in Edge that seems relevant;
Browser Link: Failed to invoke return value callback:
TypeError: Unable to get property 'files' of undefined or null reference.
browserLink (64,492)
I found the only function in the BrowserLink js that references 'files' and started going up the stack trace. It seems to expect a JSON from localhost:9640/5b39911a4f384282a7625405b2d603cf/browserLinkSignalR with multiple elements, [1] being a list of source files, but is actually null, so catches and posts that console log.
Nothing useful on Google, or their GitHub issues. If there was a relevant Github repo I could be pointed to, I could look it up.
Microsoft Visual Studio Enterprise 2015 Version 14.0.25421.03 Update 3
Microsoft .NET Core Tools (Preview 2) 14.1.20624.0
"Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0"
Edge 25.10586.0.0

I fixed this issue by removing the default browserlink package
Microsoft.VisualStudio.Web.BrowserLink
and installing
Microsoft.VisualStudio.Web.BrowserLink.Loader
Here is an updated guide from Microsoft docs
I was also getting other errors in the console about missing css with browserlink and this fixed that too.

Whenever i'm doing something new like this, i would try to find an example project that is leveraging the same feature somewhere on github. I would then build that project and see if it works. If the example project works and yours does not. I would then begin checking using statements, project configuration properties (right click project in solution explorer/properties), web config settings, includes, references and all included library versions. You should be able to figure this out by following those steps. I would be willing to bet that it is something nominal like a missing app or web config setting. Things of that nature can be difficult to detect without a working example project or proper instructions.
See this microsoft.com tutorial, although its not for the same version of visual studio, it may have some information that can lead you in the right direction.
Microsft.com Browser Link tutorial

WebSupergoo.ABCpdf Test application does not work

I recently cleaned up my Windows 7 64-bit PC, and after it ABCpdf8 started giving me an error, when I try to export HTML to PDF.
The error is "Failed to initiate IE compatibility mode: Failed to load all required assemblies."
at WebSupergoo.ABCpdf8.Internal.IECompatibility.Activate()
at line
theID = theDoc.AddImageUrl(input.Text);
of the test application, and I have no idea why, because I did not remove any assemblies from my machine.
If I run the compiled application on another workstation with the same config (Windows 7 64-bit), it works fine. Dependency Walker images showed no difference in DLLs sets from my machine and from another.
How else can I identify the source of the problem?
It is definitely neither a missing DLL, nor the user access to the system folders, because, I checked user rights as well, they're identical on both machines.
I assume that it might be a corrupted registry entry. Is there any way to quickly check the assumption?
It has to be said that, ABCpdf comes as third-party tool within another software, so I cannot contact support directly, but through the main vendor.

I had a similar problem with different behavior on w7 and ws2008, which was solved by using the Gecko engine
doc.HtmlOptions.Engine = EngineType.Gecko;
Note that websupergoo recommends using Gecko rather than IE9 as parts of the IE API it uses have been deprecated. (item 6.29)

When you 'cleaned' your system you may have erased the license key from the registry. Try re-installing your 'other software'.

VS 2010 designer error 'Could not find type XYZ' in Windows7. Works fine in XP

I'm stuck on a problem in VS 2010 C# .NET. I've had a project on Windows XP that includes forms, classes and a handful of my own custom components. These components are simple extensions of built-in MS components (e.g. DataGridViewEx as an extension of DataGridView). Everything has worked fine in XP. I'm trying to port this project over to VS 2010 on Windows 7 / x64. I've got the solution to compile OK on Windows 7, however in design mode, when I open a form that contains one of the custom controls, I get an error 'Could not find type XYZ.DataGridViewEx. Please make sure that the assembly that contains this type is referenced.' XYZ is the namespace I use for these controls and it is the same namespace as the forms that are using the controls. All are part of the same VS project.
When I open a form in the same project that does not contain one of these custom controls, that form opens OK in the designer, and I see the custom controls along the left side in the toolbox. However if I then try to drag one of these controls into that form, it pops up an error message box 'Failed to load toolbox item 'DataGridViewEx'. It will be removed from the toolbox.' And then it gets removed from the toolbox.
Everything was always working fine in VS solution in XP. This problem only occurs in the VS solution in Windows 7 / x64.
I don't understand why it complains about not being able to find the component, since the component is part of the same project. That's a valid thing to do, isn't it?
I've search the web/forums and found cases of the 'Could not find type' error, but it seemed to be caused by a different issue, and I haven't yet found a way to get rid of the error.
Any help/tips are much appreciated!

If your project is targeted at 64 bit, you need to build for 32 bit and choose the 32-bit solution while doing your GUI editing. This is because studio is 32-bit so cannot load 64-bit controls.

Ive run into this before, be sure that in your Form.Designer.cs code file, that each call to your custom controls are done so as absolute calls. For example:
Namespace.CustomControl control;
Rather than
CustomControl control;

Look at your references and find any that have exclamation point icons. Remove the bad references and add them back to your project.

Have you tried disabling UAC completely (running IDE as Administrator + disabling UAC just in case).
Also - always use Fusion Log for tracing assembly loads! See http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.71).aspx for how to set it up

Did you rebuild your components from scratch?
Are the projects included?
Are they all building?
Are they all building on the same platform (x86 vs x64)?

Set the default built to x86 and that should fix it.

Clean the solution
Build the project containing the Control
Add the control to the toolbox/form
See if this works.

For anyone who with similar issue(s). I just came across this in VS 2013 (VB side) on an x86 PC. As mentioned above, I toggled from 'anyCPU' to 'x86' and the form designer opened right up. Simple, but probably wouldn't have tried it without the above post(s). For what it's worth, I toggled back to 'anyCPU', and as yet have had no recurrences...

I faced the same error, can't able to Build my application.
So searched here, Says to change the solution platform X64 or X32.
But in my case the Solution platform only shows Any CPU and configuration manager option only
But i simply change the solution configuration.
Debug => Release
then
Release => Debug
Finally clean and rebuilt the solution. Its works for me!!:)

While the top answer from #richard-whitehead is correct that the 64bit editor cannot load the 32bit controls which is why you're seeing the error, there is another way to have Visual Studio edit 32bit GUI controls in a 64bit GUI project as described here:
https://stackoverflow.com/a/26539992/2280961

Access to the registry key is denied (ABCPdf)

I am trying out ABCPdf 8.1 and when using the AddImageUrl(...) method I get the following error:
Access to the registry key 'HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl' is denied.
I have looked in the registry and main\featurecontrol does not exist for CURRENT_USER so I cannot change permissions on it.
Has anyone experienced this before, or know of any solutions I could try?
Thanks in advance

Who is the CURRENT_USER? Assuming it's an ASP.NET application identity, have you tried loading its user profile?
Open up IIS Manager and navigate to the application pool for your site. In the Advanced Settings dialog, set Load User Profile to True.

Perhaps it's a problem between IE9 and ABCPDF.If this error comes by using AddHtml() or AddImageHtml() , I suggest you to change the Rendering Engine from MSHtml to Gecko.
theDoc.HtmlOptions.Engine = EngineType.Gecko;
http://www.websupergoo.com/support.htm
In my case, this solution solved my error.

If you know the specific key that ABCPDF is trying to add, and you don't want to change the app pool settings, you can set the appropriate key in HKEY_LOCAL_MACHINE. We had exactly that situation and knew that ABCPDF wanted to add the FEATURE_IVIEWOBJECTDRAW_DMLT9_WITH_GDI key. So we added the entries below to the registry. Note that the second key is specifically for 32-bit applications running on 64-bit Windows.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_IVIEWOBJECTDRAW_DMLT9_WITH_GDI]
"w3wp.exe"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_IVIEWOBJECTDRAW_DMLT9_WITH_GDI]
"w3wp.exe"=dword:00000001

I'm not sure if this is the answer but if you are trying to access this programaticaly your executable should run as administrator while accessing it. If you are in debug mode run visual studio as administrator (right click and select "Run as administrator"

Problem with "add reference" under Visual C# 2008 Express Edition after switching from XP to Windows 7

I suddenly have a big problem I didn't have before.
In my current project, I want to add a reference to "Microsoft.Office.Interop.OneNote". When I open the .NET tab of the "Add Reference" dialog, the "Microsoft.Office" assemblies aren't available like they used to be; on my machine, the next assembly after "Microsoft.JScript" is called "Microsoft.SqlServer.ConnectionInfo"; no trace of any of the "Microsoft.Office" assemblies. I used to be able to do this under Windows XP, but made the switch to Windows 7 a couple of weeks ago. I don't know whether that has anything to do with it.
I already checked whether the assemblies are installed on my machine, but I found all of the office assemblies safe and sound in "windows\assembly". Oddly enough, the reference to "Microsoft.Office.Interop.OneNote" in a previous project continues to work; I just can't add any new references with the "add references" dialog, as they aren't shown in the list of .NET references anymore.
Any help will be appreciated.
Kind regards,
Rainer

Pardon the perhaps stupid question.
Have you installed MS Office since you switched from XP to windows 7?
I'm only asking because I forgot to install it after the same upgrade and I spent a good half hour last week trying to figure out why my project that used Powerpoint was complaining.

the content of the dialog you see with ´Add Reference´ is actually not loaded from the GAC. It´s some registry-folder settings for visual studio.
Maybe you installed in such a way that the libraries are not part of this set. Then VS will not show them in the dialog.
for more info on how to add entries to your ´add reference´ dialog see
http://support.microsoft.com/kb/306149

I think I have got it. For the benefit of anyone who runs into the same problem, there was an interesting lesson to be learned about some lesser known features of Windows:
The link Marvin mentioned above...
http://support.microsoft.com/kb/306149
...says:
To display your assembly in the Add Reference dialog box, you can add a registry key, such as the following, which points to the location of the assembly
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\MyAssemblies]#="C:\\MyAssemblies"
where MyAssemblies is the name of the
folder in which the assemblies reside.
So I did just that, replacing "myAssemblies" with "C:\Windows\Assembly".
Nothing happened.
I changed the value of the empty standard key to "C:\Windows\Assembly".
Nothing.
I tried some variations of the theme: double backslashes, ending with a backslash, the return of the son of the backslash. No cigar.
So I tried to work the other way around by trying to copy the necessary dll from c:\windows\assembly into one of the directories that are being watched by the "add reference" dialog. On my machine, these paths are conveniently listed under
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v2.0.50727\AssemblyFoldersEx]
When I tried to copy the dll from c:\windows\assembly, there was no "copy" option in the context menu. Drag'n'drop didn't work either. For this problem, I found several alternative solutions here:
http://geekswithblogs.net/pavelka/archive/2006/05/05/WindowsExplorerAndTheGlobalAssemblyCache.aspx
I opted for solution 2:
Add DisableCacheViewer Registry Key
Another way to disable to create a new dword key under HKLM\Software\Microsoft\Fusion\ with the nane DisableCacheViewer and set it’s [DWORD] value to 1.
After I had done that, I could see the real directory structure below c:\windows\assembly; almost each and every dll has its own subdirectory. As soon as DisableCacheViewer was set, I could
traverse the real directory tree that was hidden under c:\windows\assembly
copy dlls and paste them to one of the directories listed under "AssemblyFoldersEx"
deduce the correct path to my dlls and create a fresh key to that path just below "AssemblyFoldersEx".
Thank you very much to everyone who answered, and a special thanks goes to hannes pavelka, whose blog entry helped to solve my problem.
P.S.: I'm almost certain that I never had to do this under Windows XP. IIRC, all of the interop assemblies were available without this kind of registry fumbling.