Sample only runs once

[floreseken]

So, I clone the repo and run the build.cmd script. All is fine.

I enter the /samples/standaloneapp/ folder and do a: dotnet run
Open up Chome and browse to http://localhost:5000 and blazor works, awesome.

But, now if I stop the process with CTRL-C and start dotnet run again, the app won't run.
The browser window stays blank and there is no error or exception whatsoever. Just nothing.

When I run the build.cmd in the root of the solution again and then dotnet run in the sample folder, everything works again.

Is this expected behavior? What might be the problem here?

[SteveSandersonMS]

Sorry for the inconvenience.

I'm afraid I can't reproduce this issue. Each time I run dotnet run, the StandaloneApp does start up and handles requests correctly.

But, now if I stop the process with CTRL-C and start dotnet run again, the app won't run.
The browser window stays blank and there is no error or exception whatsoever. Just nothing.

What's the output in the console the second time you dotnet run? Does it say Now listening on: http://localhost:5000 again?

If it does, can you use the browser's dev tools to find out more about what happens when it makes the HTTP request? For example, are there any JS errors in the console, or does the Network tab show the server responding with an error, or does the request hang open, or something else?

[austincummings]

@SteveSandersonMS I have the same issue. There aren't any errors in the console or network tab, and the output of dotnet run is the same.

However I do notice there's a difference in the DOM when I get the blank screen.

First dotnet run - all good

Second dotnet run - broken

I captured screenshots of the network as well if you'd like to see those.

[floreseken]

Same DOM here. Tried disabling browser cache, but that makes no difference.

[floreseken]

This is the console output of a failing run:

C:\Work\Blazor\samples\StandaloneApp>dotnet run
Using launch settings from C:\Work\Blazor\samples\StandaloneApp\Properties\launchSettings.json...
Hosting environment: Development
Content root path: C:\Work\Blazor\samples\StandaloneApp
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/
info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[6]
      The file /index.html was not modified
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 24.2063ms 304 text/html
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/_framework/_bin/StandaloneApp.dll
info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[2]
      Sending file. Request path: '/_framework/_bin/StandaloneApp.dll'. Physical path: 'C:\Work\Blazor\samples\StandaloneApp\bin\Debug\netstandard2.0\dist\_framework\_bin\StandaloneApp.dll'
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/_framework/_bin/Microsoft.AspNetCore.Blazor.Browser.dll
info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[6]
      The file /_framework/_bin/Microsoft.AspNetCore.Blazor.Browser.dll was not modified
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 0.5337ms 304 application/octet-stream
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/_framework/_bin/Microsoft.AspNetCore.Blazor.dll
info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[6]
      The file /_framework/_bin/Microsoft.AspNetCore.Blazor.dll was not modified
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 0.2954ms 304 application/octet-stream
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/_framework/_bin/mscorlib.dll
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/_framework/_bin/netstandard.dll
info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[2]
      Sending file. Request path: '/_framework/_bin/mscorlib.dll'. Physical path: 'C:\Work\Blazor\samples\StandaloneApp\bin\Debug\netstandard2.0\dist\_framework\_bin\mscorlib.dll'
info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[2]
      Sending file. Request path: '/_framework/_bin/netstandard.dll'. Physical path: 'C:\Work\Blazor\samples\StandaloneApp\bin\Debug\netstandard2.0\dist\_framework\_bin\netstandard.dll'
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/_framework/_bin/System.Core.dll
info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[2]
      Sending file. Request path: '/_framework/_bin/System.Core.dll'. Physical path: 'C:\Work\Blazor\samples\StandaloneApp\bin\Debug\netstandard2.0\dist\_framework\_bin\System.Core.dll'
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/_framework/_bin/System.Diagnostics.StackTrace.dll
info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[2]
      Sending file. Request path: '/_framework/_bin/System.Diagnostics.StackTrace.dll'. Physical path: 'C:\Work\Blazor\samples\StandaloneApp\bin\Debug\netstandard2.0\dist\_framework\_bin\System.Diagnostics.StackTrace.dll'
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 70.5572ms 200 application/octet-stream
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 80.8185ms 200 application/octet-stream
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/_framework/_bin/System.dll
info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[2]
      Sending file. Request path: '/_framework/_bin/System.dll'. Physical path: 'C:\Work\Blazor\samples\StandaloneApp\bin\Debug\netstandard2.0\dist\_framework\_bin\System.dll'
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/_framework/_bin/System.Globalization.Extensions.dll
info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[2]
      Sending file. Request path: '/_framework/_bin/System.Globalization.Extensions.dll'. Physical path: 'C:\Work\Blazor\samples\StandaloneApp\bin\Debug\netstandard2.0\dist\_framework\_bin\System.Globalization.Extensions.dll'
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 7.5246ms 200 application/octet-stream
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/_framework/_bin/System.Net.Http.dll
info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[2]
      Sending file. Request path: '/_framework/_bin/System.Net.Http.dll'. Physical path: 'C:\Work\Blazor\samples\StandaloneApp\bin\Debug\netstandard2.0\dist\_framework\_bin\System.Net.Http.dll'
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/_framework/_bin/System.Runtime.Serialization.Primitives.dll
info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[2]
      Sending file. Request path: '/_framework/_bin/System.Runtime.Serialization.Primitives.dll'. Physical path: 'C:\Work\Blazor\samples\StandaloneApp\bin\Debug\netstandard2.0\dist\_framework\_bin\System.Runtime.Serialization.Primitives.dll'
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 72.3483ms 200 application/octet-stream
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/_framework/_bin/System.Security.Cryptography.Algorithms.dll
info: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware[2]
      Sending file. Request path: '/_framework/_bin/System.Security.Cryptography.Algorithms.dll'. Physical path: 'C:\Work\Blazor\samples\StandaloneApp\bin\Debug\netstandard2.0\dist\_framework\_bin\System.Security.Cryptography.Algorithms.dll'
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 33.472ms 200 application/octet-stream
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 91.6763ms 200 application/octet-stream
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 58.0322ms 200 application/octet-stream
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 24.9669ms 200 application/octet-stream
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 99.2167ms 200 application/octet-stream
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 236.8831ms 200 application/octet-stream

[floreseken]

One more observation:

I've modified my Main to this:

        public static void Main(string[] args)
        {
            Console.WriteLine("We are in main");

            var serviceProvider = new BrowserServiceProvider(configure =>
            {
                // Add any custom services here
            });

            Console.WriteLine("Before render");

            new BrowserRenderer(serviceProvider).AddComponent<App>("app");

            Console.WriteLine("After render");
        }

And that does get written on the browser console:

[CzechsMix]

Also seeing this issue, using Chromium.
Dom output using dev tools looks the same.
Checked network on page load, and all the assets were delivered, but the app tag in the page was never replaced with the blazor app.

[floreseken]

I've also tested again in FF, same thing.

[SteveSandersonMS]

What's happening here is that, on build, for some reason it's not using the newer Razor compiler and hence doesn't recognise any of your components. Instead of compiling <Router> as a reference to the Router component, it's just outputting an instruction to create an HTML element called <Router> (which is useless and will do nothing at runtime, hence the blank white screen).

So it won't make any difference which browser you use or whether you reload, clear cache, or whatever. It's a build-time problem, not a runtime one.

The most important thing I'd like to know first is whether anyone hits this issue when working on a real Blazor app project (as opposed to when working inside the Blazor repo itself via Blazor.sln):

• If it does happen with real Blazor app projects created via the project templates, then this needs to be tracked down ASAP and we'll need your help with reproducing the issue. It's very likely to be because you have an unexpected version of something installed, but we need to know what.
• If it only happens inside Blazor.sln, then while we do still want to track it down, it's less urgent and will probably just go away on its own as newer versions of .NET CLI and VS become more standardised and there's less chance that anyone has the wrong version(s) installed.

[floreseken]

Ok. I'm on it!

[floreseken]

Okay. The good news is that is doesn't happen in a newly created project.

[floreseken]

Go ahead and release ;-)

[SteveSandersonMS]

Thanks for that info @floreseken! Release should be soon :)

[SteveSandersonMS]

If someone is able to post steps to reproduce this on a clean machine (e.g., from a fresh Win 10 installation without any .NET or VS installation, which exact versions of each thing you install. It needs to be from a clean machine, otherwise something else you previously installed might interfere.) we'd certainly have a look.

Failing that it's probably not a good thing for us to investigate since it appears that if you do have the right dependencies installed, then this issue doesn't occur (it doesn't for anyone on the Blazor team). Since our dependencies are getting rolled into the standard .NET Core SDK and VS itself, then pretty soon it will be hard not to have the correct dependencies installed so it's very likely this will cease to apply.

[SteveSandersonMS]

OK, I managed to reproduce this issue by accident.

It happens if you try to build the Blazor.sln sample projects using the wrong .NET SDK. Inside Blazor.sln, you need to be using the version specified by global.json, currently 2.1.300-preview2-008322. If instead you build using (for example) 2.1.300-preview1-008174, then it won't use the correct Razor compiler and you get the effect described in this issue.

So if you see something like this happen, run dotnet --version. If the response doesn't match the global.json contents, then your installation is wrong. Run dotnet --list-sdks: you'll probably see that you don't have the correct SDK installed. To fix it, either install the correct SDK, or more simply, change your PATH environment variable so that dotnet matches the installation that does have the correct SDK, i.e., the one that build.cmd/build.sh uses.

I know this is a bit annoying; it annoys us too! Working with prerelease versions of .NET SDK generally gets tricky like this. It's all much easier for people simply build apps using the released versions of Blazor, since that will only use released .NET SDKs.

[floreseken]

I guess you are right, turns out I do not have the correct SDK.

[floreseken]

Wait a minute.. @SteveSandersonMS

The readme getting started only mentions preview1, and the global.json says preview2, shouldn't the getting started be updated then?

[floreseken]

btw, I'm having an extremely hard time to find a download of preview2

[SteveSandersonMS]

@floreseken It's best not to download it manually. If you run build.cmd, then Korebuild will download it for you and places it in some location like C:\Users\username\.dotnet\x64\. If you then set your PATH to prefer that location (e.g., set PATH=C:\Users\username\.dotnet\x64\;%PATH%), you'll get the right SDK.

[GuruCharan94]

Faced the same issue.. Thanks for the solution..
@SteveSandersonMS This Blog post by @danroth27 needs an update to the correct SDK version.
@floreseken The correct SDK version can be found here