/clr, /clrpure, /clrsafe, WinForm CodeDOM Error

Question

Hi,
Have converted a working vs2013 project to vs2015 preview and then CTP, I get a parser error when the WinForm designer tries to redraw the form. The converted code runs and compiles fine both in debug and release modes, and it seems the CodeDOM is not
able to see the classes defined in one of the referenced assemblies, which in fact isolates the problem to the way the form designer tries to pull in these referenced assemblies. My impression was that the code has to be built using the /clrpure in particular
or /clrsafe, and the latter was the switch used for the project since vs2005. There are inquiries on the forum expressing the designer misbehavior if the switches are not accordingly used for the C++ projects. 
Now building the code with the same switch in vs2015 gives the warning that /clrpure is deprecated, and altering it to /clr or /clrsafe although all generate a running code with the winform behaving properly, does not resolve the WinForm designer error.
It is nice to know if there is a workaround for this, or a way to step within the designer code to find out exactly what the cause of error could be, using the debugger. The call stack only shows the calls within the visual studio assemblies, and testing
hypothetical workarounds for a large size project is not that feasible either.
Best Regards,
AliReza Bemanian, Ph.D.

Answer 1

Hi,
Thanks for the provided steps and precautions so well described within your email. Unfortunately I had followed those steps earlier, even generated a new solution and added the projects one by one, cleared individual components and libraries, moved around
code segments always by making sure the designer generated pragma region has been left intact.  Still, I get a single CodeDom error complaining one of the dll classes is not found.
The dll links properly with the rest of the code, and the generated exe works fine with no problem at all. The Win Form initialization routines are all placed within the code modules with the only exception of the WinForm constructor still left within the
header file, which I will try to move it to the code module and try it tomorrow. Honestly I do not think this would make a difference either.
The only exception between the project generating the error by the CodeDom and the rest is the use of DataSets. The project generates a rather large data set header file, more than twelve thousand lines of code, where I noticed even for the VS2013 there
is no namespaces to contain the defined classes at all. VS2015 utilizes a single namespace scope within the header file, but I do not understand why for every defined namespace class,  the namespace name with two columns are again used. This is for
every single definition within the header file or the namespace. Obviously there is nothing wrong with this and we used to do it sporadically to clear rare compiler misinterpretations.
Now the problem is this that the CodeDom does not show not only the class name which is not visible to the form designer but the name prefixed by the namespace , or NameSpace.ClassName. The generated DataSet header file also shows the definitions as expressed
above, all prefixed with the namespace name. although all are depicted by IDE as errors with the red underlines. If I do a code peek for these underlined error elements the error gets cleared for that single individual until the code is rebuild again.
Even I removed all the prefixes  and was able to build the code successfully, more than 800 instances. The solution ran fine again with the exception of the Win Form designer generating the same error and incapable of redrawing the form.
That is why I mentioned  earlier, "it seems the CodeDOM is not able to see the classes defined in one of the referenced assemblies". Just speculating either the CodeDom does not expect the namespace prefix or it adds an extra one make it
unusable.
I tried to convey some of my key understandings of the problem. Knowing this is only a beta version, may be I tried to port the project a bit too early, but I was really impressed and drawn into it as soon as I realized the rich newly added features
and capabilities to the VS2015, and despite the invested time  this far, would still look for a solution or may be a service update to make these tasks a bit easier soon.
Best Regards,
AliReza Bemanian, Ph.D.