On occasion, I get the following error in design mode of some user controls in Visual Studio 2008:
The file 'UserControl.vb' does not support code parsing or generation because it is not contained within a project that supports code.
It doesn't happen on a consistent basis, but it happens enough to be annoying. Are there any common causes of this error?
And yes, it is in a project that supports code - last I checked, WinForms projects typically have code in them!
It is a bug in VS. It happens in VS2005 as well.
Don't waste your time: close VS, open it again and everything should work fine.
Note that there is a Microsoft Connect issue on this: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=366006
What if the linker is encountering an exception during the build, but the exception handler doesn't have complete state information and returns that message because it's the one that corresponds to the information which it does have? If code is being generated to handle a call from one module to another rather than letting the runtime binding by the DLL loader based on the function descriptor (which should be present) in the called module do the work of setting up the call, and the compiler hasn't yet resolved all of the symbols denoting .sdata or .sbss sections, the difference between initialized and uninitialized data segments might not be flagged if the linker was expected to have that data. If the compiler generates code using link tables instead of leaving it to the linker to set things up for the DLL loader, and doesn't recognize that the import stub didn't have the value of gp (i.e., the r1 register) but, since no error was generated so far, it goes ahead and tries to calculate it and suddenly runs up against the problem that .sbss is an uninitialized data segment but has to have a function descriptor in it anyway, what does it do? I don't know how the memory allocation would work there, or how it would be represented in the object file; but if something as simple as an allocation error generates an exception and the compiler is caught at a moment when it still has incomplete state information to pass to the exception handler, it seems possible that the handler would assume that the call is due to an ownership or security issue and then activate a check to see what type of violation is implied. Finding no violations, what would the handler do then? Obviously, it would have to report that it checked and there was no error; so what then? Does it reset a flag that the compiler picks up before it checks the return value from the exception stack? What if the end result is that the compiler sees a state that looks like 'function unsupported' rather than 'unknown error'? This may sound like a far-fetched scenario; but something far-fetched has to be causing the error these people are talking about! How else are you going to imagine C# returning a message that implies there's no such thing as a code segment? Whatever it is, there has to be a 'mechanism' for it; and the most obvious thing- the thing that sticks out in your imagination -is that the compiler must not be able to generate a reference to the function descriptor for a load module, and somehow it gets handled as global. If someone good at using the kernel debugger would attach to the compiler and check which namespaces are being used- and in which order -by the code generator, linker, and exception handler, that should indicate whether the mismatch is symbolic (at the level of the source symbols) or direct (at the address binding level). The fact that this error message pops up sporadically, and almost invariably disappears when these people exit the IDE and restart it, suggests that there is an uninitialized variable somewhere which has a partial dependency on the state-spaces of other variables which don't always determine its state uniquely. I don't think it's the 'reserved bit' problem, although that's probably not impossible. If it is this type of problem, then it should be possible to add a couple of lines of code somewhere that would serve no other purpose than to cause generation of symbolic and linking information for the faulty module earlier in the build process; or if there is a flag somewhere that isn't being set correctly, to get that job done before the compiler or exception handler sees it. Since every module has to be able to address its own code, you might fail-safe it by putting exportable null routines in any header files that could be causing the problem, and see if that does the trick. At least that would make sure the .bss sections all have been allocated function descriptors before external modules are expected to be able to see them.