Hosting Blazor App on O365 Sharepoint

I probably have a larger article to write on hosting static sites on o365, especially with respect to SPA style things. But for now I’ll just make a note of this particular item here so I don’t forget or if anyone else is looking for this, they can find it. TLDR; don’t do this, at least right now.

A little background

Currently I have a SPA hosted on o365. It is just using html, custom js, bootstrap, and chartjs to show some businesses info internally. I started with a free bootstrap dashboard template. Originally a ‘dashboard’ solution, although it really is now a collection of graphs and tables that probably provide a bit more detail than a true KPI driven dashboard with some single number metrics. It works fine. There are requests to add items to it, however, from time to time that require me to do more extensive changes than I may want to the existing page. This has led me several times to consider converting it to react or using vue or some other library to make it a bit more standard. I am the only one working on it and it’s not terribly complicated so the ‘conversion’ may have minimal practical pay off. Be that as it may, I do try to look at options when a change comes up and it makes sense.

Enter Blazor and WebAssembly

I will probably always be more comfortable with batch/shell scripting as that’s where I started, but after that most of my development work was in the microsoft world. I’ve done java and a variety of other weirder languages depending on where I was, but I never studied C in school or anything so my background is more higher level programming languages. My preference has always been the microsoft world from a tooling perspective, however I always really use vscode in recent years and mostly stick to things I can produce with that as far as solutions I produce go. Lots of powershell and javascript is really where I live today. That being said, i have been watching blazor in the last year and it looked pretty cool and the idea of using c# and producing javascript sounded nice.

With the Build conference recently being virtual, I was able to get time to attend it and one of the things I was looking forward to was some info on this. Blazor was released and is now ready for production which is cool. So I grabbed the required things and played around with it a little bit. Easy enough to add some stuff into it, but then I decided to deal with my main concern/question which was can I just dump it onto sharepoint to host it there. I probably need to write an entry about how we use this and why it works for us, but for now I’ll just say that there is one main caveat for hosting static stuff right on a sharepoint site: json files aren’t allowed. The fix for this for me is I just produce json data and name it txt. Then I just parse it as json. No biggy. But for something like blazor, I figured some of the build steps may require json files or things to be in certain locations and I was right.

How to make it work

So, first I’ll say I did not go all the way through with getting this fully setup. But if you just start with dotnet new blazorwasm -o MyApp that will get you an app. Then you can cd MyApp and dotnet publish -c Release /p:TrimUnusedDependencies=true to get some files you can push out as a static site. To get to these you can just start .\bin\Release\netstandard2.1\publish\wwwroot\ if you are in that folder and you’ll see the files you need to copy. You’ll need to rename the html file to aspx for it to work. You will also need to change the base value in the html page to point to your actual base folder. For me I have this as a subsite in another site and I am using a publishing site which already has a Pages library. So I changed my base to something like <base href="/mySite/mySubSite/Pages/" /> and that seemed to allow the webassembly js to load. However if you copy it all out just like that, it won’t work. Since I have run into issues with json files in the past, I figured this was probably the case as well. Since the html has a single script file reference to _framework/blazor.webassembly.js I just started randomly debugging in there for what was going on. This was kind of impossible with the generated file so I used beautify to format it in vscode and then pushed it out there. In hindsight I could have just searched for .json since I kind of knew what I was looking for, but stepping through it was I guess interesting and I was hoping I would get some meaningful info. These are pretty optimized functions though so it’s not really easy to read. Anyway, down towards the bottom you can find fetch("_framework/blazor.boot.json"..... which is really the culprit. Adding a suffix of .txt and adding .txt to the end of the actual file name and uploading it again seems to do the trick. This allowed the web app to load and I could see counter and the main page. I think the default route may need to be tweaked and there are other items that may need to be tweaked similarly, but it did work.

Why I don’t care

After all this, I could finally check what the download experience was like and how heavy the framework was. Just looking at the files in the build output, you can see at least like 10MB. If I left the dependencies in there (omitting that build flag) it was about double that. I also tried compiling it for linux and a couple of other ways and only was able to tighten it up to about 9MB. Now I could probably get this down further, but the goal was to gain time. My current payload is pretty tiny as I’m just using some light js libaries for some utility and charting and the usual bootcamp/jquery type of things. My usual payload is about 500k for any and all dependencies. So while this is maybe cool if I am going to switch to a server side setup in the future (which only sends the pieces of the framework you need) right now having to send the whole thing down just makes the app way too fat for me. If I was building a much richer app, then it might be different. But for now the real, and already existing, benefits of ease of securing things in o365 sharepoint and the free nature of hosting a kind of custom interface for our users with a very tiny size far outweighs any potential benefits from a tool like this.

But you never know unless you give it a shot. 😀