Water unable to build simple .NET Test projects

For some reason, I am unable to build projects using Water on my system. These are projects that were created either with Water or with Visual Studio 2022, they are newly created so nothing has been changed other than the template selection, and the projects build successfully using Visual Studio 2022. These are Mercury projects. The project templates I have tried so far include:

  • ASP.NET Core MVC/Razor-based Web Application
  • Console Application (Classic .NET)
  • Console Application (.NET Core)
  • Windows Forms Application (Classic .NET)

This is with Elements version on Windows 10.

When I try to build any of these projects, this is the error I get:

Object reference not set to an instance of an object.
at RemObjects.Fire.ProjectSystem.RunAndDebugHelpers.stringForCommand____parameters(String command, List`1 args)
at RemObjects.Fire.ProjectSystem.BuildRunner.<>c__DisplayClass0.<beginBuildWithArguments>b__0()

Here’s an example of one of these projects:
WaterWindowsFormsClassicNET.zip (65.9 KB)

I did try completely uninstalling Water/Elements, rebooting Windows 10, and then reinstalling, but that did not resolve it.

Suggestions welcome.


that’s weird, I rechecked the same build to be sure and it’s working as expected.
What’s your windows user name?


This looks like it cant find EBuild.exe. Can you run ebuild ok from the command line?

What’s your windows user name?

“alovhaug”. Here’s the path to one of the solutions as an example:

C:\Users\alovhaug\Documents\RemObjects Software\Elements\Water\CP.AI.Mercury.VS\CP.AI.Mercury.VS.sln

This looks like it cant find EBuild.exe. Can you run ebuild ok from the command line?

Running ebuild from the command line seems to work fine.


Very strange. What changed since this last worked? did you just update from an earlier version to is this a fresh install?

I’m sorry to say I really don’t know when this started.

I haven’t had much of an opportunity to work with Water or Mercury in the last several months. Occasionally I would update to the latest version, but I wasn’t really building any projects or anything. I did try completely uninstalling and reinstalling, but the problem still exists (is that a fresh install? Maybe not.)


I’ll see if tomorrow I can look top where thios comes from, and see if I can either add logging for Fridays build OR send you a small tool that does some local checks… :crossed_fingers:t3:

Sounds good. No rush, as obviously I can work around the problem via Visual Studio or the command line.


Do you have the “Use .NET Core version of EBuild tool chain and compiler” option enabled in Water’s Preferences? If so, as a temporary workaround, can you turn that off and see if that fixes/works around the problem? Also, what Architecture is our OS? ii86, x64 or arm64?


Oh my goodness - I had “use .NET Core version of EBuild tool chain and compiler” checked. After unchecking it, builds work just fine!

I’m so sorry - I’ll bet I tried that out when it was first announced, and then completely forgot about it. If I had remembered that was still checked, I would have have tried that out. I seem to recall that this was very particular about having a specific version of .NET core installed, and perhaps what I have installed isn’t correct.

FYI - The OS processor is x64.


No, this is good, as tis was a real bug.

ive uploaded RemObjects Elements with Water - to your personal downloads, which should fix this, can you retest (both turn the option back on and check the first line of the build log that it actually runs the Core version (because I also added a fix that it should fall back to non-Core if Core cant be found. But it should be found ok now.

This was a side effect of adjusting the Architecture names used by Core, a few weeks back.

New version works! Turning the option back on again and building the project from Water is now compiling instead of generating an error.

It does seem to be running the Core version - here’s the first line of my build log from one of the projects I created for testing:

"C:\Program Files (x86)\RemObjects Software\Elements\Bin\Core\EBuild-win-x64.exe" --logger:fire "C:\Users\alovhaug\Documents\RemObjects Software\Elements\Water\WaterMVCRazor\WaterMVCRazor.sln" --configuration:Debug --build --setting:TreatFixableErrorsAsWarnings=True --build-missing-projects "--xml:C:\Users\alovhaug\Documents\RemObjects Software\Elements\Water\WaterMVCRazor\obj\WaterMVCRazor.water.xml" --no-goal --debug --statistics --verbosity:diagnostic

Thanks, Marc - I continue to be impressed by your fantastic support!


Excellent! I’m happy to hear that.

yep, thats the core one. My fix a few weeks back changed x86_64 (our name for the architecture, and the official one) to x64 (Microsoft’s one for .NET Core), but the code that looked for the .exe still looked for EBuild-win-x86_64.exe.

Ahhhh…makes sense.

I remember thinking at the time it was made available that improving build times is awesome. I have one solution in particular that takes a long time to build, and I was hoping to move it to Elements. Unfortunately, the project involves a third party CMS, and that vendor isn’t going to support an alternative compiler. :frowning:



Cant you just reference that as compiled .dlls build in VC# or whatever it is written in?

Cant you just reference that as compiled .dlls build in VC# or whatever it is written in?

The vendor provides a C# project that I make modifications to with our customizations. Since C# isn’t my favorite and I prefer VB.NET, my idea had been to convert it to an Elements multi-language project, and then anything new could be in Mercury and over time I could perhaps convert my old C# code to Mercury too. But I realized that I end up sending them my project for support at least once or twice a year, so I don’t think that is going to work.

But you are right, there are also several separate class libraries that are referenced and those could be moved to Mercury. I think the build times on those are considerably smaller, though.


Ah. good idea.