I'm using DotNetBrowser and currently when I close my application I get the error System.InvalidOperationException in DotNetBrowser.dll (Channel is already closed).
When attempting to debug why this was occurring, I opened up the exception's details and found something strange. The StackTrace, TargetSite, DeclaringType, ReflectedType, etc., are all written backwards.
Is this because DotNetBrowser wrote their code backwards? Is this a bug with Visual Studio? What's going on?
Dot net adds RTL markers in the text.
copy the text in a text editor(notepad or so) hit CTRL + Home, type a ' single quote, CTRL + END type: '.split('').reverse().join("") (It will appear reversed but will still do it's stuff correctly)
Open a browser, hit f12, move to console and paste the the entire document and hit enter.
so in this case:
console.log('egassM.segassM.CPI.slanretnl.resworBteNtoD('.split('').reverse().join(""))
And then you have the readable message in your console.
This is the worst type of security.
You may notice that some entries are written backwards, some are messed up and some other entries are missing.
The release build of DotNetBrowser is obfuscated and protected, that's why the stack trace entries related to its internal logic are unreadable.
Related
I'm using a custom logger(log4net) for Unity, following this guide. This involves making a custom appender that writes to Unity's console using Debug.Log(). All of this works great, however the problem is that whenever a log statement is printed it originates from the custom appender. So when I double click the message in the console I end up opening the code for the appender and not the source code from where the message originated. I want to print a clickable hyperlink in the console to the path of the source code.(I already have the path)
It seems the Unity console already supports clickable links:
I just don't know how to make it print links that I want.
In IDE's such as Intellij the console automatically parses links,so I tried to print the path for the source in the unity console for example:
(at Assets/Scripts/MovablePlatform.cs:)
But this didn't work
TL;DR
I want to know if it's possible to print clickable link in Unity's console such as 'http://www.google.com' or 'file:///D:/Mysourcode/main.cs'
Rich text supports anchor tags for file paths, but it doesn't appear to support URLs. Your example would be:
Debug.Log("Assets/Scripts/MovablePlatform.cs:7");
Logging a link like asset works for creating asset links since Unity 2019. This is the same mechanism used internally by Unity for clickable stack traces (also introduced in that version). The path must reference an existing Unity asset (not just any file).
Note, however, that while the link renders in blue in the main list of debug log messages, it isn't clickable there, only in the detailed pane below (which also shows the stack trace). That is, you must first click the log message, then click the link in the detailed message pane.
(Finally, in my testing I occasionally hit what may be a Unity bug or a bug in the Rider IDE integration, where I sometimes have to Alt+Tab away from Unity and back before it will open any asset link, stack trace links included. I assume doing so resets some sort of state in Unity's asset database, which is why it fixes things.)
Since Unity 2021.2.0a11, both web links and file links are supported:
Debug.Log("Click me: local file");
Debug.Log("Click me: website");
You can now even hook into the hyperlink handling and do whatever you please with the result using EditorGUI.hyperLinkClicked.
UnityEditor.EditorGUI.hyperLinkClicked += (window, args)
=> Debug.Log($"clicked link to {args.hyperLinkData["href"]} in {window}");
so you can even implement your own ad-hoc links (by using other attributes than href, to avoid clashes).
As far as I know, no.
Those links are there so that you can jump to any of the calling methods in the stack trace that resulted in the Debug.Log call, and all you have to do is scroll down. Unity added this feature precisely because of log appenders but the system is entirely managed by Unity. Double-click is still going to go to the actual Debug.Log line, but you can still access other lines via those "hyperlinks" but they are built automagically by Unity and there is no API for writing those links yourself.
If you don't want your log appender to lose that information, don't do whatever it is that is making Unity lose that information when you use your log appender. You didn't include your code, so why the extra information is being lost is unclear. Also check your console settings and that you are using Unity 2019.1 or newer.
An open source Unity Console plug-in is recommended to solve this problem. Click console-hyperlinks!
I am writing some C# code with visual studio and I have a weird behavior with brackets. Let's see an example.
First I write this code:
Then when I add a single bracket with AltGr + Shift + [ I get this:
The entire class gets selected. How can I avoid this? The issue came out after the update to the latest version.
I am using the latest version of everything. I have VS 15.8.0, C# 7.3 and the .NET 4.7.2, any idea?
Please note that some times, after a { the entire class gets selected and I am not able to type the closed bracket }.
This happens when I write C++ as well. (like a new Console App). I have tested it right now in an empty project and the issue is here on C++ as well (VS 15.8.0, C++17). I have added a random c++ function to a library of mine and I have this behavior like in C#!
Possible solution
When I get the entire text selected, I press esc and the text gets deselected (plus the cursor is still at the right place). This is annoying AND this wasn't a problem 2 hours ago (when I had the old version).
I have an Italian keyboard and I can reproduce this behavior after the update. The fact is:
AltGr + Shift + { adds an open bracket as expected
AltGr + Shift + } selects the entire declaration of the class/struct in which you are creating the method
I wasn't able to find the keyword map that generates this behaviour (under Tools > Environment > Keyboard).
A solution may be the following: be sure that you have the automatic bracket completion enabled (which is already, by default) and type only the open bracket. In this way, when you type { you automatically get the closed bracket.
What if you need to type a } then? Well, you can use Alt + 125 and you'll get the close bracket (open bracket is Alt + 123.
For the tl;dr crowd:
What is causing type names to be written to the output window if it isn't Console.WriteLine or Debug.Print statements in the code? Is it the Visual Studio debugger? and
How can I turn it off?
Background and details:
I am trying to debug a program that imports CSV files into a database. Recently, I changed how I include 3rd party library dependencies. Previously, I was referencing the downloaded binary files. Now, if a 3rd party library has source code available, such as NHibernate, the project is included in my solution to be compiled along with the projects I have written myself.
Since the change, I am seeing a lot of single lines containing only a type name in the Output/Debug window that I didn't used to see before. My program is a data importer, and the main loop is causing these lines to appear 1000s of times, slowing down debugging and polluting the output window. Specifically, there are a lot of lines that say this:
NHibernate.Driver.NHybridDataReader
I have traced the code, and it seems that this is displayed whenever NHibernate is reading results back from the database. However, the line isn't output in code by the NHibernate library, so it must be coming from somewhere else. My guess is that the Visual Studio Debugger is writing it to the output window, similar to what happens during assembly binding.
I have tried compiling the NHibernate project in Release mode and everything else in Debug mode, but that didn't fix it. I also tried unchecking "Enable the Visual Studio hosting process" for just the NHibernate project, but that didn't work either.
In summary, my questions are:
What is writing type names to the output window if it isn't Console.WriteLine or Debug.Print statements in the code? and
How can I turn it off?
What my question is not
My question is NOT about a better way to write the data importer program so that the needed data is preloaded from the database. I know the code I have written is slow; in this particular case, in production, that is okay. What I want is to stop polluting the debug window with tons of unneeded type information. The work loop of my program causes the types to be written 1000s of times for long CSV files, which makes the output hard to use, and slows the debugger down as it tries to sync the output window. THIS is what I am trying to prevent. But I'm not sure how to do that, because I'm not even sure where the messages are coming from.
It's difficult to make suggestions without being able to see the code, but what I would do to debug it is install the trial version of RedGate's Reflector and use it to add breakpoints to the Debug.* and Console.* functions. If one of the breakpoints is hit, you can trace back up the call stack to find what is actually adding the lines to the output. If none of those methods are causing the lines to be added, maybe add breakpoints to DefaultTraceListener and TextWriter.
I haven't come across anything else which can add messages to the Visual Studio output window at run time.
I think this is irrelevant, though it solved my seemingly unrelated problem a while back (I had automated tests randomly failing and printing to console). I had to uncheck Visual Studio's "Enable property evaluation and other implicit function calls" under the Debugging menu in Options. Sorry if this is off topic/unhelpful!
EDIT: Also, have you tried changing the 'Output Window' settings in the Debugging section? You could maybe turn all debug output off and print your own debugging to a file.
I would post a snippet, but I honestly have no idea what part of my code could possibly be doing this. The program is sizable, I don't want to make you all wade through it. What kinds of things could possibly be the cause of this? Everything works perfectly when called from the command prompt: "readoo.exe". But when I click the exe in its file. . . "readoo.exe has encountered a problem and needs to close. . ."
this is intended to eventually be a scheduled task -> i'm worried, will it work?
i've never debugged, all i've ever used is notepad. I am learning, and feel that this strengthens my understanding of a project.
it crashes nearly immediately. there are no shortcuts, though the file paths are relative.
trying this method: shortcut -> properties -> shortcut -> Start In. I don't have a "shortcut" option
my program reads log files, parses, and creates 4 new files based on the found content
Microsoft Error Report says file not found. But how can this be? the files are there, albeit relative.
Take a copy of your project, and then start hacking bits out of it. When it no longer crashes, you've removed the bit causing the problem.
At what point does it fail when you double-click on it? Immediately, or only when you take a certain action?
You could also add a lot of logging to it, which could indicate where the problem is too.
This is probably looking for a dll that it can't find or is finding a different version from what it wants.
You could try Process Monitor or Process Explorer from sysinternals to see what dlls it loads when it does work and where it finds them.
Try putting a System.Diagnostics.Debugger.Break()call as the first thing in Main() and you'll be asked to attach a debugger - this should definitely show you what is different betweent the 2 invocations.
I would start with identifying what is different in the two methods of execution. Is there a shortcut modifying anything?
The starting directory?
The execution account?
command line arguments?
There are 2 things that it could be:
The current directory could be different when you click on the program or run from the command prompt.
The settings and path could be different when you click on the programe you are using the standard command prompt, are you opening the visual studio command prompt when you run the program from the prompt.
If your application relies on some file that should be on the same path of that exe, that can occurr.
You will have to change the properties of the exe (or shortcut to the exe) to "Start In" the directory where your exe is. For a shortcut, right click on the shortcut -> properties -> shortcut -> Start In.
I guess that is what I think could be the cause.
EDIT: Add a Console.ReadLine towards the end of your code to make it pause for you to see any exception thrown. That should help when you run it using windows explorer.
Put a try/catch around your code and output the exception message to the console in the catch block. That should give you some clues.
#error shows in errors, #warning in warnings. How can I make a line of text appear in the messages filter of the Error List window?
To clarify:
If I place the following line within a C# code file, it will generate an error on build, and that error will appear in the Error List window if I switch the errors on (like tabs above the list, there are buttons to toggle Errors, Warnings, and Messages).
#error This will cause a divide by zero
The same can be done to inject warnings into the build output:
#warning This might produce a NullReference exception
What would I place in the C# code file to have a message like that appear in the Messages list?
You may use TasksList. On the View menu, point to Other Windows and then click Task List.
The Task List is displayed.
In the Categories list, click Comments.
The Comments list displays the comment text and appears there whenever you open and edit the code file. You can click any Task List comment to activate the file in the Code Editor and jump to the line of code that the comment marks. You may use //TODO, //HACK, //UNDONE or you specified custom comments.
The short answer: You can't.
If you want to communicate with the builder of your code, use warnings or errors as these appear in all builds, not just in Visual Studio.
I think this is what you are looking for:
http://www.mztools.com/articles/2008/MZ2008022.aspx
I stopped by this question because I was searching to do the same from my AddIn written in C# for Visual Studio 2010.
After a couple of minutes I finally got the answer in that link!
Unsure what you are asking? You basically want to see those errors and warnings displayed?
This may sound very basic but:
1) Make sure your Error List is displayed fully by making the window bigger so you see the headers Description, File, Line...
2) Click on the # Errors and # Warnings buttons at the top.
We tend to do what necrostaz suggested. We've defined our own INFO tag so we can put // INFO This is a message.
It would be good to find a way to generate an informational message, though.