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:
This is with Elements version 12.0.0.2927 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()
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…
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.
ive uploaded RemObjects Elements with Water - 12.0.0.2928.exe 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.
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.
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.
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.
