|
Bugzilla – Full Text Bug Listing |
| Summary: | Solution doesn't compile if code uses any IsolatedStorageFile method such as DirectoryExists | ||
|---|---|---|---|
| Product: | [Mono] MonoDevelop | Reporter: | Ezequiel Pérez <eazel7> |
| Component: | general | Assignee: | Michael Hutchinson <mhutchinson> |
| Status: | RESOLVED FIXED | QA Contact: | MD Bugs <monodevelop-bugs> |
| Severity: | Critical | ||
| Priority: | P5 - None | ||
| Version: | 2.2 | ||
| Target Milestone: | 2.4 | ||
| Hardware: | i586 | ||
| OS: | openSUSE 11.2 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | 574582 | ||
| Bug Blocks: | |||
| Attachments: | Sample code for the description above | ||
more info: If you create a new moonlight solution and open up the Classes tab, expand "References" and double click on mscorlib, the metadata on the right shows: // Assembly mscorlib, Version 2.0.0.0 It correctly shows 2.0.5.0 for all the other assemblies. Fixed in r148781. Under some circumstances when resolving paths from full assembly names, MD would resolve any assembly name starting with "corlib" to the running corlib's path - despite having resolved the correct assembly name and package for the target framework. I suspect that the codepath was intended as a fallback to ensure basic code completion in all cases, but I don't think there's much value in incorrect code completion, and in this case it broke the correct code completion and the assembly browser. The compilation is still broken, but it seems to be a Mono/smcs issue rather than MD. smcs is loading the 2.0 corlib instead of the one in the directory beside it. If I set MONO_PATH to that directory, I get a runtime error about smcs not being able to access System.Environment.GetEnvironmentVariable. The smcs script is helpful in this regard. the command line looks like: mono --runtime=moonlight --security=temporary-smcs-hack .../smcs.exe the word "temporary" there really isn't accurate: the hack is going to go away for a long while. Turns out that MONO_PATH is needed as well as those args, else mono looks for mscorlib in $prefix/lib/mono/2.1, and ignores the one beside smcs. As a workaround, one can create a script called "smcs" in the moonlight/2.0 SDK directory. However, MD picks up smcs.exe and tries to execute it directly, so it must be moved into a subdirectory (moonlight/2.0/hack) to force MD to use the script instead. #!/bin/sh export MONO_PATH="`dirname \"$0\"`" mono --runtime=moonlight --security=temporary-smcs-hack "$MONO_PATH/hack/smcs.exe" $* So, the question is how we should fix this. IMO MD shouldn't have to worry about these magic flags, but if MD has to look for the smcs wrapper in PATH then the SDK can no longer trivially be versioned, and can no longer be distributed as a directory that can be patched into MD with a single environment variable. Should we have a smcs wrapper script in the versioned SDK directories, and hack MD to prefer the wrapper over the exe in the case of smcs? That seems like an easy fix. If we can put it directly in the 2.0 directory, I'd like that more (than the 2.0/hack). Definitely think the wrapper script in the 2.0 directory is a good thing. Oh, also I had to use MONO_PATH including both 2.0 and 2.0-redist to compile some of these assemblies. sorry about not updating this bug sooner. Why do you have to include redist in MONO_PATH? I thought we were passing full paths for those. (In reply to comment #8) > Why do you have to include redist in MONO_PATH? I thought we were passing full > paths for those. that's a good question - we shouldn't have to, but compiling something locally ended up failing due to not being able to find System.Xml.Linq. let me remove the extra MONO_PATH and see where exactly where it's failing. MD now prefers the script over using the exe directly, so the hack directory is no longer needed. Does the Moonlight SDK include the smcs script in the 2.0 directory yet? I've added a tracking bug to moonlight for this. the fix is in trunk, but we need to backport it to the 2.0 branch for the 2.0 update. So, can this bug be closed? Yes, I think so. |
Created attachment 333545 [details] Sample code for the description above User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091103 SUSE/3.5.5-1.1.2 Firefox/3.5.5 I'm on opensuse 11.2, installed using the repos you have in the download page for it if I do new IsolatedStorageFile.GetUserStoreForApplication () it compiles but if I do anything else like storage.DirectoryExists("mydir") it doesn't compile saying CS1061 (no method or extension method found, missing reference?) although, if I run the app only with the storage instantiation like I wrote above and I debug, I can execute the method using reflection doing the call from the immediate window fails saying incorrect arguments I guess that what was happening is that it is: retrieving the intellisense info from a version, compiling against a version that does not have the methods (!?) but in runtime as it is a core library of moonlight it is overwritten with a good version and it has the methods Reproducible: Always Steps to Reproduce: 1. Install mono, monodevelop, moonlight packages on a clean openSuse 11.2 from the repos announced in mono homepage 2. Install moonlight plugin from moonlight homepage 2. Run MonoDevelop 3. Create a new moonlight project 4. In Page.cs after this.InitializeComponents() add the following code: var storage = IsolatedStorageFile.GetUserStoreForApplication (); if (!storage.DirectoryExists ("Scripts")) { storage.CreateDirectory ("Scripts"); } 4. Press F5 to run Actual Results: Fails to compile with Error CS1061 saying no method or extension method DirectoryExists could be found Expected Results: Compiles the solution and browser opens, running the application everytime