Unable to view content or schema on new install of Squidex

I tested it on my local IIS and it worked properly

I just deleted the Squidex and SquidexContent db’s in MongoDb (V4.0.0), pulled down the latest code from the master branch and ran a “dotnet publish” command. I then navigated to the bin/Debug/netcoreapp2.2/publish folder and ran “dotnet ./Squidex.dll”. I was presented with a blank Squidex install and selected to create the “Blog” app. As soon as I did and clicked on “Content” I received the same error - “failed to make request”.

I do notice in the logs that there are alot of warnings from Orleans and when I use Ctrl+C to shut down there are alot of errors.

Is there a data store for Orleans that may be corrupt and causing this ? Is there a way to wipe that clean ?

If you have deleted your databases then it is already cleaned. Are you hosting it on the root level or a nested app?

I’m hosting it from the command line on my development laptop (with full admin privileges), using “dotnet ./Squidex.dll” in the “publish” folder. Running it like this exhibits the same issues as when I host it within IIS.

The only time it works is when I run in dev mode using “npm start” and “dotnet run” in the “Squidex/src/Squidex” folder.

Can you try to install the latest SDK and runtime? I am a little bit lost, right now :frowning:

Another idea: If you return true here: https://github.com/Squidex/squidex/blob/master/src/Squidex/Config/Logging.cs#L21 it will log everything. If you change it, then publish it and try it again the log will be probably huge, but could contain some useful information.

I will try the SDK update first, then your suggestion for “complete” logging.

Another thought… is it possible to prevent the minification of the js so that its easier to see where the exception is being thrown ?

You could run it with the development server using ASPNETCORE_ENVIRONMENT=Production

I just tried exactly the same like you: Reinstalled docker then dotnet publish and it was working fine :frowning:

Was running 2.2.103 of the SDK so updated to 2.2.108 (latest version that supports dev studio 2017) and 2.2.6 of the runtime. Same problem.

Changed the logging, no additional errors showed in the logs.

Are you able to track back from the js error that is raised ?

Just return true

public static void AddFilters(this ILoggingBuilder builder)
        {
            builder.AddFilter((category, level) =>
            {
                return true;
                if (category.StartsWith("Orleans.Runtime.NoOpHostEnvironmentStatistics", StringComparison.OrdinalIgnoreCase))
                {
                    return level >= LogLevel.Error;
                }
               
                ....
        }
}

Then publish (dotnet publish) it again and you should see a lot of logs. I think the JS error is irrelevant.

Actually, after taking a fresh windows server and installing all that was needed and using my local build, I still received the same error. So I deleted my clone of the master branch and re-cloned - thinking it must be something to do with the codebase I have.

Now I’m getting errors trying to build the latest code on the master branch…

1>obj\Debug\netstandard2.0\Squidex.Domain.Apps.Entities.orleans.g.cs(2386,45,2386,52): error CS0246: The type or namespace name ‘TagsSet’ could not be found (are you missing a using directive or an assembly reference?)
1>obj\Debug\netstandard2.0\Squidex.Domain.Apps.Entities.orleans.g.cs(2386,106,2386,118): error CS0539: ‘OrleansCodeGenTagGrainReference.GetTagsAsync()’ in explicit interface declaration is not a member of interface

Ok… sorry, past that issue now

What do you mean with that?

My initial attempt to build the latest code did not succeed… i cleaned up some obj code and then rebuilt and it all compiled.

I’ve given up trying to build the production environment locally and am using your binaries instead. They work fine.

It is running now? WTF

Sorry for not being clear.

I am not able to build your code from GitHub and have it work… I’m going to chalk that up to my environment is not clean enough for that to happen.

However, and I didn’t realize, that you provide pre-built binaries and after installing them in my production environment (still dev/staging at the moment) they worked great.

Sorry for the distraction this last week or two.

1 Like