Activity overview
Latest activity by JB47394
I continued to hammer away at this and it seems that the dynamic load has nothing to do with the problem. I wouldn't put money on that claim because I could swear I could control failures by twiddling references in Visual Studio - but after more testing, it seems that it's entirely an issue of assembly attributes.
There were two (of four) assembly attributes that needed to be removed if the profiler was going to run.
[assembly: PermissionSet(SecurityAction.RequestOptional, Name = "Nothing")]
and
[assembly: FileIOPermission(SecurityAction.RequestOptional, Unrestricted = true)]
Once removed, the process ran normally while being profiled.
SecurityAction.RequestOptional is listed as being obsolete, but there are two other assembly attributes in the same DLLs that use obsolete SecurityActions that do not block the profiler:
[assembly: SecurityPermission(SecurityAction.RequestMinimum, Execution = true)]
and
[assembly: SecurityPermission(SecurityAction.RequestRefuse, UnmanagedCode = true)]
I haven't tried twiddling with this stuff because I don't have a clue what it does. / comments
I continued to hammer away at this and it seems that the dynamic load has nothing to do with the problem. I wouldn't put money on that claim because I could swear I could control failures by twidd...
I probably should have mentioned a somewhat unusual usage pattern from the start: I'm dynamically loading an assembly (Assembly.LoadFrom), and that assembly is the only thing in the application referencing the third party DLL.
I have another windows application that directly links to the third party DLL, and that profiles just fine. So I created a direct link from the console application to the third party DLL and now the console application profiles just fine. No actual calls to the third party DLL are needed; just the reference.
Do I need to stick with this workaround or is there some way for me to tell the profiler that this situation exists? Is there a particular usage pattern for dynamically loading assemblies that I should follow in order to make the profiler happy? / comments
I probably should have mentioned a somewhat unusual usage pattern from the start: I'm dynamically loading an assembly (Assembly.LoadFrom), and that assembly is the only thing in the application re...
Thanks for the reply, Brian. The new DLL does have SecurityPermission attributes, but taking them out didn't change the behavior. It also has CLSCompliant attributes, which I have not touched as they would be a little more work to remove.
Everything I have is .NET 2.0, including the new DLL. Is there anything special that I can do with the profiler to get it to operate exclusively in that space? In the thread you linked, there's mention of something that can be done with a test web server, but I'm working with a console application. I can find no setting in the profiler user interface that suggests a solution. / comments
Thanks for the reply, Brian. The new DLL does have SecurityPermission attributes, but taking them out didn't change the behavior. It also has CLSCompliant attributes, which I have not touched as ...
VerificationException only when profiling
Windows 7 x86
Visual Studio 2010
C#
Ants Performance Profiler 6.2.0.13 Standard
I'm looking for help in nailing down a problem that crops up only when I attempt to profile my application.
I have a ...