Open GoogleCodeExporter opened 9 years ago
Also, Hi Dan! Small world, huh?
Original comment by bencurth...@gmail.com
on 18 Dec 2009 at 3:12
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:
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
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
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
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
Original comment by jeff.br...@gmail.com
on 18 Dec 2009 at 8:01
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
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
Original comment by Yann.Tre...@gmail.com
on 19 Jul 2010 at 9:16
Original comment by Yann.Tre...@gmail.com
on 22 Jul 2010 at 7:27
Original comment by Yann.Tre...@gmail.com
on 14 Jun 2011 at 5:53
Original issue reported on code.google.com by
bencurth...@gmail.com
on 18 Dec 2009 at 3:10Attachments: