Does not parse ProjectReferences? about fsautocomplete HOT 16 CLOSED

Thanks for reporting, but I don't think this is a bug. Basically, it has parsed the project references, which is why it is expecting to find sample.dll under the output directory of the default configuration according to the test project file. This is bin/Debug as indicated by the Vim error message, but the ProjectScaffold builds in the Release configuration, so they aren't found. I'm pretty sure this would happen with Visual Studio as well. To work around it you just need to build in Debug mode (C-c C-c RET in emacs should do it while in Tests.fs), or change the default configuration in your project file to be Release. I think really this mismatch is a bug in ProjectScaffold.

from fsautocomplete.

for completeness just run :make in vim to achieve the same.

On Fri, 10 Jul 2015 at 11:42 Robin Neatherway [email protected]
wrote:

Thanks for reporting, but I don't think this is a bug. Basically, it has
parsed the project references, which is why it is expecting to find
sample.dll under the output directory of the default configuration
according to the test project file. This is bin/Debug as indicated by the
Vim error message, but the ProjectScaffold builds in the Release
configuration, so they aren't found. I'm pretty sure this would happen with
Visual Studio as well. To work around it you just need to build in Debug
mode (C-c C-c RET in emacs should do it while in Tests.fs), or change the
default configuration in your project file to be Release. I think really
this mismatch is a bug in ProjectScaffold.

—
Reply to this email directly or view it on GitHub
#39 (comment)
.

from fsautocomplete.

@rneatherway - I believe it should be possible to use FCS inter-project references to get multiple projects working without requiring the compiled DLLs on disk (Visual Studio F# Tools does require dependent DLLs on-disk for its checking functionality, but Visual F# Power Tools added functionality does not).

Are you using GetProjectOptionsFromProjectFile which does the recursive parsing of referenced project files?

from fsautocomplete.

@dsyme thanks for mentioning it. I'm currently not, but it should be a simple change. I thought that it was still in testing, so I hadn't tried using it yet. If you think it is worth using I will definitely switch, that will be a nice improvement.

from fsautocomplete.

Yes, give it go, it should be stable.

The only area I know of that might need to be looked is what happens if a project in Release mode references a project in Debug mode (assuming that's even allowed). I've never quite worked out exactly how Visual Studio manages such things - is that info recorded in the solution file? I think it must be, since it seems absent from the project files.

from fsautocomplete.

Yes, that's right, it is stored in the solution file. Projects contain a default value (which I have only ever seen to be Debug) so that they can be built separately. I expect that the referencing project would take priority, as the Configuration would already be set when the referenced project was imported.

We may have to consider parsing/using solution files at some point, see another discussion about implementing multi-project symbol usage.

from fsautocomplete.

Juts a note: using GetProjectOptionsFromProjectFile adds quite a degree of latency (can be 3-4 seconds), I use an LRU cache with expiration based on the project changing.

from fsautocomplete.

(And it currently doesn't work on Android, iOS classic, iOS unified, Mac unified, and MonoMac projects)

from fsautocomplete.

@7sharp9 - Does that apply specifically to GetProjectOptionsFromProjectFile (which @rneatherway is not yet using) or also to FSharpProjectFileInfo.Parse (which @rneatherway is already using)

from fsautocomplete.

Either, its the parse which calls msbuild which causes the latency. To use it without caching I had to set the time to 10 seconds.

from fsautocomplete.

Oh, and also if you do multiple calls without some form of lock it can cause a memory leak.

from fsautocomplete.

@7sharp9 - OK, thanks. Re locking - yes, this should be moved to the FCS reactor thread. I'll add an FCS issue on that. It would also make sense to add an FCS cache for this though I suppose that's lower priority.

from fsautocomplete.

The thing with the cache is a project needs to be removed if it changes where it would result in different results, and possibly dependent projects may need to be recalculated depending on the change. At the moment I have project change event simply clear the cache.

from fsautocomplete.

I assume the project change event is a Xamarin Studio thing? Perhaps I could use a FileSystemWatcher for the same thing.

from fsautocomplete.

I currently clear on:

    x.OnFileAddedToProject
    x.OnFileRemovedFromProject
    x.OnFileRenamedInProject
    x.OnFilePropertyChangedInProject
    x.OnReferenceAddedToProject
    x.OnReferenceRemovedFromProject

from fsautocomplete.

OK, I plan to fix this, but it will involve significant changes to the way that I get the project options, and I am looking at how best to remove the background agent anyway, so that will happen first.

from fsautocomplete.