Is there something wrong with the .dll file? Shouldn't it just consider the code as closed source since it's all byte code and try NOT to step through it? Is there any way to make this possible?
For example, I have an ASP.net MVC 3 project which is using both Fluent NHibernate and NHibernate. Regardless of which version I use, I can't debug what is happening without having actual access to the source code.
This, I believe poses a problem, for I've installed the necessary binaries to build the project, and therefore SHOULD be able to just debug and get the necessary information available on my variables without stepping through the code itself. If this is not the case (which it isn't, obviously), what can I do about it?
Note: my whole goal here is to see if it's possible to debug my code WITHOUT requiring the source files, as I have the .dll installed, and therefore shouldn't require the source to view the data that variables hold on the stack.
Check to see if Just My Code is enabled in your debug options and settings.
From above link:
Sometimes, while you are debugging, you might want to look at only the code you have written and ignore other code, such as system calls. You can do this with Just My Code debugging. Just My Code hides non-user code so that it does not appear in the debugger windows. When you step, the debugger steps through any non-user code but does not stop in it.
Related
I am not new to coding and I know I have never had this issue.
In Visual Studio if I just create a .cs file and check it's intellisense nothing works. auto complete for using. does not work, nor does simple syntax checking work (see image)
Am I crazy? Can someone else try this out, what am I missing?
NOTE this only happens when I just have a .cs file for an external script. I just need simple auto complete and syntax checking to work
A C# file is somewhat meaningless without a project file. Versions, references, etc… all depend upon having a build system. This is a somewhat pedantic truth, but it is how VS works. Pathologically, I could have a CS file Console.WriteLine(“Hello world!”); which in one project results in hello world, and in another results in the program formatting a disk.
Add the CS file to a project, or create one. If you frequently come across this issue in some unique use case, visual studio may not be the best editor for the job. VS Code or another more lightweight tool may be better suited.
I am a total noob with Application Insights, and sadly for a whole day of trying I have been unable to get it working at all. I tried with the following code:
this.telemetryClient = new TelemetryClient(TelemetryConfiguration.CreateDefault());
this.telemetryClient.TrackTrace($"Test", Microsoft.ApplicationInsights.DataContracts.SeverityLevel.Warning);
But when I go to the application insights window and show all telemetry from the current debugging session there is nothing logged. One user said an ApplicationInsights.config file is missing (and that an empty one would do fine for debugging), I created one but it changed nothing.
Then I tried the simplest console app I could find - https://learn.microsoft.com/en-us/azure/azure-monitor/app/console . I don't have an instrumentation key, and from the hundreds of forums I read today, if you leave it blank it should still appear in the debugging telemetry. Alas, still nothing in Application Insights.
How can I get it working? I just want to see a single Trace message in the Visual Studio Application Insights window when queried for "debugging telemetry".
I used to work on this stuff and the way it generally works, the extension tries to figure out if it should watch for debug output, and if it doesn't recognize the project type, we do nothing (to avoid doign work in the debugger when we don't need to). in this case, console apps aren't a "known" supported project type.
IIRC, to get debug output I believe you need to do 2 things, of which you've done 1:
1) add an ApplicationInsights.config file at the root of that project
2) add an application insight resource id to to the csproj:
<ApplicationInsightsResourceId>/subscriptions/abc</ApplicationInsightsResourceId>
i don't think the resource id even needs to be valid, but if it does even better, because then other things can light up, like exceptions codelens, various links to the portal/etc.
you migth only need to do #2?
i think that if you do the above and restart vs/reload the solution, you should see the debugger integration try to do work when the debugger starts. (it used to!)
So, I'm profiling my application, and I'm getting 30% exclusive samples on System.Windows.Forms.Application.Run, of which almost the entirety is on "Function Body". However, I can't see what is exactly happening there, as Visual Studio tells me "Matching symbols could not be found".
I've tried adding manually the System.Windows.Forms.pdb file, which's pathI got from Debug->Windows->Modules, to Options->Debug->Symbols, to no avail.
I also generated the respective pdb file and added it similarly, with no luck.
I've also tried setting Debugging->General->Enable .Net FrameWork Source stepping to true, and disabled Just My Code, in the same menu. No luck at all
Is there any way this can be done? I really want to know what the hell is happening in that function body that's taking a third of CPU time.
I have this problem:
I made a C# WPF (.NET Framework 4.0) application and everything is ok. Now I want to obfuscate it. I tried with Confuser.
The question is:
If the app is published I can see the main exe file and dll-s. So I tried to obfuscate the exe. Where should I put the obfuscated .exe generated file (I obfuscate only the main exe file). I mean Confuser creates a folder called "Confuser" with the obfuscated exe in it.
If I doubleclick the obfuscated exe to start the app as usually it doesn't work and I get the normal application crush window.
I also tried to replace the original exe file (in the app folder) with the obfuscated one (from Confuser folder).
If the app is deployed I have the setup.msi pack or setup.exe. How should I obfuscate in this case ?
Thankx,
Adrian
All XAML-based platforms (WPF, Silverlight, Windows Phone) are quite problematic area for most obfuscators. The main problem is that XAML references types and members by name. No wonder the applications often doesn't work after obfuscation: the integrity breaks.
There are two ways that are used by obfuscators to keep the output assembly work afterwards:
Search XAML content for everything that could be a type or property name and then roughly exclude all members that anyhow match these names. This doesn't give 100% guarantee that the application is not broken while makes the obfuscation coverage poor because of the inaccurate analysis. Still this approach can potentially save your application from breaking.
Do something similar to what XamlReader does: load XAML tree and find all matching CLR types and members. After renaming all the changes are synchronized with XAML. This approach gives the best reliability and coverage (types and members are renamed both in the code and XAML). There are obfuscators on the market that claim that they support XAML renaming. You may want to try some of them.
There is also a workaround. Most obfuscators support conditional obfuscation allowing to manually exclude specific types and members. You should manually exclude all the types and members that are somehow referenced by XAML. This will take some time but usually works.
First, you obfuscate your main .exe file and replace the old one. Then you pack everything into installer.
Also make sure all the properties and types involved in xaml are declared as public. Or tell the obfuscator to ignore them somehow.
I'd experiment with a simple console app first. Make sure you can get it working with that.
Then I might progress to a simple WPF app.
The problem with WPF and obfuscation is it relies on reflection. The View Models are bound by name. It could be this obfuscator isn't sensitive to this, or you need to configure it to ignore the names of properties on your view models.
If you've any other reflection using name, that could break it too. Even a Enum.Parse call can be tripped up. Maybe you seralize to/from XML, that is also a point it could break at.
You may want to display the exception that the app is crashing with to help you debug, but I would get comfortible with the tool myself with simple apps to work out how it gets around the above issues.
Trying to debug a controllers action method, and when I attach to process the debug icon goes hollow and says the 'current breakpoint will not be hit'
But I am doing a response.write at that point and when the page renders it does output the test text.
So that section is indeed being executed, why does debug mode not work?
Your source code may be different than the version of the corresponding process that you are attaching to. Your other process may also be built in release mode, i.e., there is no debug info.
There are a few reasons why you may see this message:
You are attached to the wrong process
You are attached to the right process but the AppDomain hasn't loaded the assembly yet
You are attached to the right process but you have forgotten to build so the source code and the PDB file are out of sync
I've noticed this happen when using reflection and dynamically loading .dll projects. If the code isn't specifically reference (i.e. you are using interface animal but dynamically loading implementations of animal such as cat/dog) it will say it won't hit the breakpoint, but actually does.
I do not like to play with knives but the only thing that worked for me involves editing the .csproj file itself. So, unload the project file, edit it by cutting and pasting the three asp.net files so that they are together in the ItemGroup. However, sometimes it is necessary to go further as explained here: http://carnotaurus.tumblr.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same - Also, I give a list of other proposed solutions that did not work for me. I hope it helps.
Another reason is when you attach to the process to quickly.
For example, when I attach to Excel to debug a VSTO add-in (I am using Add-In Express), if I Build, then Start > Run > Excel, then quickly press Ctrl+Alt+P to attach to process, then press E to highlight Excel and press Enter I see this, before Excel has loaded:
The result is no Breakpoints will be hit.
However, if I give Excel a couple of seconds to load and then press Ctrl+Alt+P, notice the Title is showing:
The result is Breakpoints will be hit.
It also tells me your source code is different from the version but it is not true. I build the whole solution, then attach to process, but still it says the breakpoints won't be hit because the source code is different. Maybe it is a bug?