[Mono-dev] base call hoisting (error) and MonoDevelop w/Moonlight

ted leslie tleslie at tcn.net
Fri Jul 9 17:31:58 EDT 2010

I have built a successful

from::   co svn://anonsvn.mono-project.com/source/trunk/

but on the monodevelop I get errors:

This error:

./MonoDevelop.AspNet.Gui/AspProjectDom.cs(91,50): error CS0584: Internal compiler error: base call hoisting
./MonoDevelop.AspNet.Gui/AspProjectDom.cs(91,25): error CS1579: foreach statement cannot operate on variables of type `object' because it does not contain a definition for `GetEnumerator' or is not accessible

has been posted here (by someone):


I came across the same issue. (so doesn't appear to be unique to my build/environment)

I "fixed" it, by:

changing in AspProjectDom.cs
// created GetInheritanceTree2  in ProjectDomDecorator.cs (copy of GetInheritanceTree, but no override).

		public override System.Collections.Generic.IEnumerable<IType> GetInheritanceTree (IType type)
			foreach (IType t in (IEnumerable<IType> )(base.GetInheritanceTree2) (type)) { 
				yield return CheckType (t);

The same "base call hoisting" error also occurs for MoonlightFrameworkBackend.cs 
// where again I create a GetToolsPaths2 from the bases GetToolsPaths

		public override IEnumerable<string> GetToolsPaths ()
			foreach (var f in GetFrameworkFolders ())
				yield return f;
			foreach (var f in base.GetToolsPaths2 ())
				yield return f;

Now monodevelop builds successfully. 

The error "hoisting" or "base call hoisting" and other derivatives , doesn't get much useful return by
googling. I don't see any reason why the compiler doesn't like it, but there may be some deep routed reason?
It doesn't appear the error name/description is useful. I am guessing there is a better name/description that
could be used? that would create a valuable return of info from googling?
For my own education, what is "base call hoisting"? perhaps with some more info I can get some useful google hits.

Now the fix above, may not have even been a useful cludge?
As I still have to cludge my MD Moonlight project to build sucessfully. (the default project).

If i create a new Moonlight app in MD, when I build the first time I get:

Building: testmoon2 (Debug)

Performing main compilation...
Generating codebehind accessors for App.xaml...
Generating codebehind accessors for Page.xaml...
Packing resources...

Unhandled Exception: System.ArgumentException: Path is empty
  at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] in <filename unknown>:0 
  at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
  at System.IO.File.OpenRead (System.String path) [0x00000] in <filename unknown>:0 
  at ResourcePacker.Pack (System.Collections.Generic.List`1 files) [0x00000] in <filename unknown>:0 
  at ResourcePacker.Main (System.String[] args) [0x00000] in <filename unknown>:0 
Build complete -- 1 error, 0 warnings

---------------------- Done ----------------------

Build: 1 error, 0 warnings

build it again, and it is successful! (just at building, app doesn't run) (error in checking deps.?),
but it created a 0 size testmoon2.g.resources   file

if I manually at shell:
 xamlg -sl2app:testmoon2.dll Page.xaml,Page.xaml.g.cs
 respack obj/Debug/testmoon2.g.resources App.xaml,App.xaml Page.xaml,Page.xaml

then "run" in MD
I get a sucessfully running Moonlight plugin showing in my browser.

Since the "hoist" error effects the GetToolsPath in Moonlight  (in MD), it may be the reason for my 
MD moonlight build issue. If not, then there seems to be two seperate issues.
The fact that MD errors once, then not the next time, and "appears" to generate a successful moonlight
app, only to have to give a "blank" plugin (in browser), probably isn't correct behavior, even if I
somehow  F'd up my install? (check for empty *.g.resources file?)
(but I like to think I did the install like anyone else would have).

ted leslie <tleslie at tcn.net>

More information about the Mono-devel-list mailing list