search

ananthoju / mb-unit

Automatically exported from code.google.com/p/mb-unit
0 stars 0 forks source link

Custom Serializable Dictionary Cannot be debugged under Gallio; works fine at runtime #598

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Load "ClassLibrary1" of attached project into Gallio
2. Press "Start"; observe test passes
3. Press "Debug"...

What is the expected output? What do you see instead?
Expected: pass
Actual: 

System.ArgumentException: Item has already been added. Key in dictionary: 
'cor_debugging_control_424242'  Key being added: 
'cor_debugging_control_424242'
   at System.Collections.Hashtable.Insert(Object key, Object nvalue, 
Boolean add)
   at System.Collections.Hashtable.Add(Object key, Object value)
   at System.Collections.Specialized.StringDictionary.Add(String key, 
String value)
   at ...

What version of the product are you using? On what operating system?

3.1 build 397, WinXP

Please provide any additional information below.

This problem did not occur in Gallio 3.0. I just upgraded in order to fix 
the "stepping through in debug mode is incredibly slow" problem, and ran 
straight into this. 

Attached project is as minimal as I can get it.

Original issue reported on code.google.com by bencurth...@gmail.com on 18 Dec 2009 at 3:10

Attachments:

GoogleCodeExporter commented 9 years ago 
Also, Hi Dan! Small world, huh?

Original comment by bencurth...@gmail.com on 18 Dec 2009 at 3:12

GoogleCodeExporter commented 9 years ago 
Pinned it down to the line 

            Class1 x = new Class1();
            XmlSerializer ser = new XmlSerializer(x.GetType());

Far simpler example attached. Nothing to do with my serializable dictionary, it 
just 
doesn't like me constructing an XmlSerializer. 

System.ArgumentException: Item has already been added. Key in dictionary: 
'cor_debugging_control_424242'  Key being added: 'cor_debugging_control_424242'
   at System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add)
   at System.Collections.Hashtable.Add(Object key, Object value)
   at System.Collections.Specialized.StringDictionary.Add(String key, String value)
   at 
System.CodeDom.Compiler.Executor.ExecWaitWithCaptureUnimpersonated(SafeUserToken
Handl
e userToken, String cmd, String currentDir, TempFileCollection tempFiles, 
String& 
outputName, String& errorName, String trueCmdLine)
   at System.CodeDom.Compiler.Executor.ExecWaitWithCapture(SafeUserTokenHandle 
userToken, String cmd, String currentDir, TempFileCollection tempFiles, String& 
outputName, String& errorName, String trueCmdLine)
   at Microsoft.CSharp.CSharpCodeGenerator.Compile(CompilerParameters options, String 
compilerDirectory, String compilerExe, String arguments, String& outputFile, 
Int32& 
nativeReturnValue, String trueArgs)
   at Microsoft.CSharp.CSharpCodeGenerator.FromFileBatch(CompilerParameters options, 
String[] fileNames)
   at Microsoft.CSharp.CSharpCodeGenerator.FromSourceBatch(CompilerParameters 
options, String[] sources)
   at 
Microsoft.CSharp.CSharpCodeGenerator.System.CodeDom.Compiler.ICodeCompiler.Compi
leAss
emblyFromSourceBatch(CompilerParameters options, String[] sources)
   at 
System.CodeDom.Compiler.CodeDomProvider.CompileAssemblyFromSource(CompilerParame
ters 
options, String[] sources)
   at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, 
XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
   at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] 
xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, 
XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable 
assemblies)
   at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] 
types, String defaultNamespace, String location, Evidence evidence)
   at System.Xml.Serialization.XmlSerializer.GenerateTempAssembly(XmlMapping 
xmlMapping, Type type, String defaultNamespace)
   at System.Xml.Serialization.XmlSerializer..ctor(Type type, String 
defaultNamespace)
   at System.Xml.Serialization.XmlSerializer..ctor(Type type)
   at ClassLibrary1.UnitTests.Test() in 
C:\SourceCode\TestSerialise\ClassLibrary1\UnitTests.cs:line 18

Original comment by bencurth...@gmail.com on 18 Dec 2009 at 3:31

Attachments:

GoogleCodeExporter commented 9 years ago 
This looks very much like the same issue:
http://social.msdn.microsoft.com/forums/en-US/asmxandxml/thread/4476f044-bab9-49
2d-
bb94-4e0960bd2d26

'cor_debugging_control_424242' isn't anything to do with me - does Gallio 
create this 
as some kind of environment variable in the debugging process, and if so, does 
it 
create two copies that differ only by case?

Original comment by bencurth...@gmail.com on 18 Dec 2009 at 3:36

GoogleCodeExporter commented 9 years ago 
I dumped out the environment variables in my unit test

IDictionary environmentVariables = Environment.GetEnvironmentVariables();
foreach (DictionaryEntry de in environmentVariables)
{
     s.AppendLine(String.Format("  {0} = {1}", de.Key, de.Value));
}

and I found

  Cor_Debugging_Control_424242 = 1

and 

  cor_debugging_control_424242 = 1

Original comment by bencurth...@gmail.com on 18 Dec 2009 at 4:08

GoogleCodeExporter commented 9 years ago 
Adding 

Environment.SetEnvironmentVariable("Cor_Debugging_Control_424242", "");

to my code before using the serializer gives me an adequate workaround for now. 

I have searched the source I just checked out, and I can't find anything that 
looks 
like it sets that variable or anything like it, but in the v2 folder there is 

bool isProfiling = Environment.GetEnvironmentVariable("cor_enable_profiling") 
== "1";

so that cor_ syntax looks like it's one of yours. Probably just a typo in some 
debug 
code you forgot to remove before shipping.

Original comment by bencurth...@gmail.com on 18 Dec 2009 at 4:11

GoogleCodeExporter commented 9 years ago 
The v2 folder is irrelevant for Gallio, that's the old MbUnit v2 stuff.  In any 
case,
there's no harm in checking for "cor_enable_profiling."

I have no idea where the "cor_debugging_control_424242" environment variable 
comes
from.  Actually, I'm more than a little concerned that it's possible to create 
an
environment that has duplicate variables differing only in case.

If I had to guess, I'd say this variable were being set by the Visual Studio
debugger.  Perhaps we get duplicate variables when a debugged process itself 
launches
another process under the debugger that inherits its environment.

I can see that when you're starting the tests, you're actually launching Icarus 
with
the debugger.  Then when you click Debug, Icarus launches the tests in a new 
process
with the debugger.

So it would see that we should add some code in Icarus to clear
"Cor_Debugging_Control_42424" before launching tests with the debugger.

Incidentally, you might find it faster to run & debug your tests using
Gallio.Echo.exe with the /r:IsolatedAppDomain argument instead of using Icarus.

Original comment by jeff.br...@gmail.com on 18 Dec 2009 at 8:00

GoogleCodeExporter commented 9 years ago

Original comment by jeff.br...@gmail.com on 18 Dec 2009 at 8:01

GoogleCodeExporter commented 9 years ago 
Whilst coding and debugging with MbUnit, I got used to starting the UI from 
Visual 
Studio debug, and it would execute the tests immediately within the Visual 
Studio 
process. I preferred using the Gui to explore test results, and to select an 
individual 
test for execution (if necessary). 

Is this not supported any more then - you're supposed to use the command line 
exe when 
starting from Visual Studio? If so, what's Icarus for?

Original comment by bencurth...@gmail.com on 21 Dec 2009 at 12:28

GoogleCodeExporter commented 9 years ago 
This usage is still supported but there's just a bug when you launch Icarus 
with the
debugger then attempt to run tests in debug mode.  I'll need to add some code to
clear the offending environment variable.

I actually recommend running Icarus separately outside of Visual Studio.  You 
can
still debug them but you'll get better performance in the GUI and you won't 
encounter
the problem described above.

Original comment by jeff.br...@gmail.com on 21 Dec 2009 at 8:19

GoogleCodeExporter commented 9 years ago

Original comment by Yann.Tre...@gmail.com on 19 Jul 2010 at 9:16

GoogleCodeExporter commented 9 years ago

Original comment by Yann.Tre...@gmail.com on 22 Jul 2010 at 7:27

GoogleCodeExporter commented 9 years ago

Original comment by Yann.Tre...@gmail.com on 14 Jun 2011 at 5:53