[Monodevelop-devel] Notes from VS builds

[Michael Hutchinson]

Hi all,

Over the weekend I brought the MD project files to a state where MD
main can be built and debugged in VS from a clean SVN checkout. It's
still pretty rough, but here are my (also rough) notes from the
problems and potential problems that I found.

Note that same of these changes make a "make-less" build of MD possible too.


* MD writes "." values for icons elements in some csproj files. Breaks
build. [RESOLVED]
  Removed offending elements. Not sure if I should file a bug against MD.

* WarnAsError breaks build since CSC has more warnings [RESOLVED]
  Disabled WarnAsError for now.

* Some pointless csc variable scope errors [RESOLVED]
  Renamed variables where necessary.

* Very picky about implicit references [RESOLVED]
  MD local copies a lot of files during the build to keep mcs happy,
then deletes then afterwards. VS just seems to require explicit
references to everything.

* Autotools-generated files : BuildVariables.cs and
MonoDevelop.projects.dll.config  [RESOLVED]
  Committed these to SVN, so autotools is no longer necessary before
first compiling MD. Autotools will still update BuildVariables when
version numbers in configure.in change. The .config file is now
platform-independent.

* The make-based build of Cecil doesn't work, and this affects a lot
of projects [RESOLVED]
  Added working project files for Cecil.

* WindowsPlatform not built [RESOLVED]
  I added DebugWindows and DebugMac solution-level configurations that
build only the appropriate addins.

* Need Nunit 2.2
  UnitTests specifies nunit 2.2 locked version

* Need GTK# 2.8 dlls for build, since we've locked referenced GTK# version

* Some projects ref GTK# > 2.8 [RESOLVED]
  Fixed refs.

* Unwanted local copy of referenced projects in many places [RESOLVED]
  Marked not to local copy.

* Unwanted local copy of GTK#, nunit, mono.cairo, mono.posix etc
  Do we have to put these in the GAC to stop VS local copying them?

* string mainRep = "http://go-mono.com/md/" +
AddinManager.CurrentAddin.Version + "/main.mrep"; fails if Mono.Addins
has already loaded another local-copied version of the IDE assembly
and the hashes do not match in the Mono.Addins internal assembly list
  Maybe the hash should be on the assembly name and not the location.
Is this a Mono/>NET difference?

* Local copy of autotools, aspnet, moonlight template files isn't
where the addin expects [RESOLVED]
  Changed deployment paths to match what local copy does.

* IDE data files (build/data) are not copied by build process
  The files in build/data aren't copied during the buiold.

* mdrun & mdtool build to a directory too far up [RESOLVED]
  Fixed output  location.

* startup project not stored in .sln [NOT POSSIBLE]
  AFAICT the startup project isn't stored with the sln.

* Need x86 target for MonoDevelop.Startup to be able to debug on
x86_64 [RESOLVED]
  Added Debug|x86 configurations for Mono.Startup, mdrun and mdhost,
added platform=x86 flags, map these to DebugWin32 solution config.

* XmlTextWriter.Settings is null by default on .NET, so calling
writer.Indent causes NRE.
  Should use XmlWriter factory instead. File a Mono bug?

* Mono.posix move call fails silently, so "safe writes" of text files
in various places do not work.
  Maybe this needs to be handled by the platform service.

* Mono.Addins' remote reflection process runs as .NET 1.1, can't read
2.0 assemblies?
  Had to build local M.A. with .NET 2 to fix. Not 100% sure what was
going on here.

* Mono.Addins: [MethodImpl(MethodImplOptions.NoInlining)] should be
added on methods that contain Assembly.GetCallingAssembly (); calls
[PATCHED IN LOCAL MONO.ADDINS]
  Don't know if lack of this actually breaks anything but it might be
good to do just in case.

* Mono.Addins: Runtime dependencies' paths / are not mapped to Windows
paths \, breaks Autotools, xml, aspnet, moonlight [PATCHED IN LOCAL
MONO.ADDINS]
  Breaks addins that have file dependencies

* SdiWorkbenchLayout has hardcoded /

* ProcessHostController invokes Mono [PATCHED LOCALLY]
  Should just be able to invoke the mdhost exe directly, except that
it's passing --debug to Mono if MD's in debug mode. My patch invokes
the exe directly unless MD's running on Mono *and* is in debug mode.

* Remoting using TCIP-IP is blocked by the firewall
  Should we use use the .NET 2.0 IPC channel instead of "unix"? IIRC
on Linux the IPC channel is Unix sockets anyway.

* VS upgrades ProductType minor version number (SP1?)
  Maybe we should update.

* VS adds <SubType>Component</SubType> to a few files in project files
  Not sure why.

-- 
Michael Hutchinson
http://mjhutchinson.com