Title. See screenshot. (yes it is with the Island.Shared project but this is still way to much.)
The max I would reason with is 1.5GB, since the entire .sln size is quiet big and he has to ref alot and stuff. Idk, or is there a setting I may have screwed up with ?(I cant remember that I did tho… but who knows…)
I restarted it and since 2 min it stays at 500mb which is very fine, I will inspect that value. …
And as I see (for the 3.time now) it crashes out nothign, when I copy code segments to another place for instance, without any error, it closes.
Can you retest this with todays build, when it’s out? we made some improvements to memory consumption.
How do you arrive at this determination?
Sure thing!
I mean VS uses that much, its a ~ value I give, which Im personally ok with, nothing calculated 
I will add this error here too since it seems very likley to be strongly related to the instant-crash:
That happened when I tried to click on the references: "Manage References"
Sadly tho I am not able to open “Manage References” anymore, im constantly getting this exception. but maybe this is fixed for next build.
very unlikely.
that said: do you have steps for this? In assume from the error details that you’re using there Add References dialog, but what exactly do you do to trigger the error? Suffice to say I cannot repro this (I’m using your project)
The steps are:
also RE-Resolve doesnt do anything.
it seems that those two are related; it looks like something major broke with your Water install. I just reviewed the code where the NRE happens, and the only way it could imagine it failing is if something is majorly wring with the installed base references.
Can you do the following, form the command line, build your project using
ebuild /path/to.sln --rebuild --debug --debug-reference-resolving
I’d hope it fails the same way, and the log file will give me an indication of why. Alternatively you can also pick the “References” node in Water, and it will also show a (less detailed) resolve log that might indicate why it cant resolve any of the references.
Please send me the log from the above command, and we’ll see next steps. By guess is the fix will be to re-run the Elements installer — but lets hold off on that unti after w elected the problem.
@mh
Sry i forgot to actually tell you this; since i was concerned about the memory consumption earlier, i tried to add also the VS extensions to water, and thus I have started the elements setup and it might have broken there smth, my bad if thsat is possible, atleast this sounds smth like that, the way you describe that.
here the log:
-> Task RemObjects.EBuild.CleanSolution started.
-> Project ConsoleApplication2 started.
-> Task RemObjects.EBuild.Elements.ElementsCleanProject started for ConsoleApplication2.
-> Task RemObjects.EBuild.CleanProject started for ConsoleApplication2.
<- Task RemObjects.EBuild.CleanProject finished for ConsoleApplication2, took 0,0010s (0.002s).
<- Task RemObjects.EBuild.Elements.ElementsCleanProject finished for ConsoleApplication2, took 0,0000s (0.008s).
<- Project ConsoleApplication2 finished, took 0.026s.
Project 'ConsoleApplication2' cleaned successfully.
Solution 'ConsoleApplication2' cleaned successfully.
<- Task RemObjects.EBuild.CleanSolution finished for ConsoleApplication2, took 0,0400s (0.040s).
-> Task RemObjects.EBuild.BuildSolution started for ConsoleApplication2.
-> Project ConsoleApplication2 started.
-- Task RemObjects.EBuild.Elements.ElementsProjectPreBuildTask skipped for ConsoleApplication2, condition not met.
-> Task RemObjects.EBuild.Elements.ElementsBuildProject started for ConsoleApplication2.
-> Task RemObjects.EBuild.Elements.ElementsExpandCopyToOutputDirectoryPaths started for ConsoleApplication2.
<- Task RemObjects.EBuild.Elements.ElementsExpandCopyToOutputDirectoryPaths finished for ConsoleApplication2, took 0,0010s (0.000s).
-> Task RemObjects.EBuild.Elements.ElementsApplyLegacySettings started for ConsoleApplication2, Island-Windows.
Mapping AssemblyName=ConsoleApplication2 to BinaryName in Target Island-Windows
<- Task RemObjects.EBuild.Elements.ElementsApplyLegacySettings finished for ConsoleApplication2, Island-Windows, took 0,0010s (0.000s).
-> Task RemObjects.EBuild.Elements.ElementsSanityCheck started for ConsoleApplication2, Island-Windows.
<- Task RemObjects.EBuild.Elements.ElementsSanityCheck finished for ConsoleApplication2, Island-Windows, took 0,0000s (0.000s).
-> Task RemObjects.EBuild.Elements.ElementsPreparePlatforms started for ConsoleApplication2.
Preparing target 'Island-Windows' (platform 'Island').
D: Target-specific Settings, before prepare
D: - <BinaryName = ConsoleApplication2 [Target: Island-Windows]>
D: - <Mode = Island [Target: Island-Windows]>
D: - <SubMode = Windows [Target: Island-Windows]>
-> Task RemObjects.EBuild.Elements.ElementsPreflightIsland started for ConsoleApplication2.
E: SDK Folder is not set up in IslandPaths.xml.
<- Task RemObjects.EBuild.Elements.ElementsPreflightIsland failed for ConsoleApplication2, took 0,0040s (0.004s).
D: Target-specific Settings, after prepare
D: - <BinaryName = ConsoleApplication2 [Target: Island-Windows]>
D: - <Mode = Island [Target: Island-Windows]>
D: - <SubMode = Windows [Target: Island-Windows]>
<- Task RemObjects.EBuild.Elements.ElementsPreparePlatforms failed for ConsoleApplication2, took 0,0080s (0.008s).
<- Task RemObjects.EBuild.Elements.ElementsBuildProject failed for ConsoleApplication2, took 0,0000s (0.013s).
<- Project ConsoleApplication2 failed, took 0.013s.
Project 'ConsoleApplication2' failed to build.
Solution 'ConsoleApplication2' failed to build project 'ConsoleApplication2'.
<- Task RemObjects.EBuild.BuildSolution failed for ConsoleApplication2, took 0,0140s (0.014s).
PS C:\Users\shho3\OneDrive\Dokumente\RemObjects Software\Elements\Water>I mean if it really had to do with the foolish try of reinstalling/Adding the vs extension, i have no problem with reinstalling (but I will wait anyway for the next build…) so there is hopefully not smth broke within water, if its due to my mistake, all good then .
I have no idea what that means.
In any case, can you run the abkive command and give me the output? also, please check the following things
in %APPDATA%\RemObjects Software\Elements\Reference Paths\Island\Elements.xml
do you have an entry like this:
<?xml version="1.0" standalone="no"?><paths><path name="Elements Core References for Island">/Users/mh/Code/Elements/Bin/References/Island</path></paths>
and does the folder it points to exist?
and in %APPDATA%\RemObjects Software\Elements\IslandPaths.xml do you have an entry like this:
<?xml version="1.0" standalone="no"?><paths><sdkFolder>/Users/mh/Code/Elements/Bin/Island SDKs</sdkFolder></paths>
and does the folder it points to exist? My gut feeling is No, and it would explain the NRE (I’ve added proofing for that now).
and bingo was his name-o.
what does this tell you?
I tried to manually add this:
the vs stuff in the setup is not clicked, but i want to point out that I have already started back then the VS stuff to add to the Enviroment path and so on and he tried and said that im using water so he cannot finish the addition of the VS stuff etc…
and yep, I can repro the exact same NRE in Water (oddly not in Fire, it just shows an empty list) when I delete/rename my `C:\Program Files (x86)\RemObjects Software\Elements\Island`` folder so it cant be found anymore.
N to sure what happened but you either deleted that or deleted the above-mentioned XML files. Reerunning there Elements installer should fix your problem, and next weeks build should no longer NRE for this (still broken) scenario.
glad to here this.
you mean the really next weeks builds or u mean with that the todays build, which is up for next week
I mean next week’s build. todays build is already running, and wont get the changes I just made.
But in either case, this fix shouldn’t be important, as it only hits with a broken install, which will be unusable anyways 
