That's interesting - thanks for letting us know. We'll look at changing the URLs to YourAssembly_dll or something like that, though whether we do it by default may depend on whether we get more reports about this, and whether we can establish it's due to the name or deeper inspection of the payload contents.

@SteveSandersonMS just to drop my 2c here. It is not just corporate firewalls that suffer of the .dll-fobia. Some local anti-virus have this same problem too.

@galvesribeiro is right not to mention that if I wasn’t familiar with what’s going on and I saw a website trying to download a DLL I’d be out of there! Consider the perception when addressing this :)

@joeizy yeah, I totally agree with you that for the majority of cases block dlls is the right thing todo. That is Why we are talking about renaming it as we are sure what we are doing...

How about YourAssembly.blazor? It might be a nice way to promote the project (very very slightly) if any web devs folks look in the dev tools to see how the site was built? Or maybe it's just just me that sometimes spots that a site was a built with Vue.js or whatever and thinks "oh, nice" :)

How about simply .bin?

I like .bin or .blazor as well.

+1 “.bin”

.lib or .bin or .ilasm ?

So we can make an informed decision about this, it would really help if we had approximate repro steps (or at least some hint in that direction). We need to understand specifically whether it's a naming issue or a content issue, for example.

What specific firewall product is known to block .dll, either by default or in a common configuration? Can you point me to something I can install and try out? Or if not, do you have the name of it at least, and perhaps links to any of its configuration docs?

@SteveSandersonMS I think it is not a particular product. Multiple products, specially the ones heavily used by enterprises have tide config settings on file types specially the common ones like .exe, .dll, .so, etc.

The name itself is the first blocker but, one way to _reduce_ this issue, is the same way we've dealing with ClickOnce since .Net 2.0. Signing assemblies.

The problem is that (1) it is not cheap, (2) the process to earn those certificates even if you can afford them is VERY complex and even not available in some countries and even if you get it, (3) the certificate for the company/developer usually takes a while to be _trusted_ by the antivirus software database.

For MSFT released assemblies, it is not a big news as we know that every shipped assembly, even OSSed ones, are code signed by corpnet policy. But think about other developers, startups, and OSS projects. They will all suffer with that.

I remember that in the good old days when Silverlight was a thing, if we wanted to download assemblies on demand, we put them in a xap file (which in practice is a zip file) and then extracted them with
https://msdn.microsoft.com/en-us/library/cc190632(v=vs.95).aspx

Not sure if there was a reason for that (other than combining multiple dlls in a single file). I guess the Silverlight team should be familiar with the firewall issues if there are any.

The problem with bundling together is that if you need to update 1 of those dlls the whole package must be updated... Not cache or bandwidth friendly the Silverlight model...

I'm not suggesting to use bundling for Blazor. I'm just saying that apart from the bundling feature, maybe the Silverlight team was using xap files to avoid firewall issues. That's just a guess, of course.

Keep ".net" as extension

We're well into the realms of bikeshedding on this now. Hence I'm specifically asking for concrete examples of actual firewall products that have trouble with this.

I think it is not a particular product

Nonetheless, examples of particular products, and under what configurations this happens, would help.

@SteveSandersonMS I understood that part. The point is that fix the issue for 1 particular antivirus/firewall will not cover all the others as we all know that each one has its own heuristic, database, settings for that. The only case that could cover both the naming and signature rules for everything, is:

1. Sign the assemblies as usual and;
2. Make sure the naming is not in the _default_ blacklist

@SteveSandersonMS I've seen a few issues when using NOD32 from ESET and have seen the active scanner block downloading some binary files silently, these seem on the face of it to be Dynamic Link Libraries that do not have a digital signature.

Thanks for the info @grahamehorner. Do you know roughly what the repro steps would be? If I just installed NOD32 onto a (throwaway) Windows machine, is that enough to make it unable to open https://blazor-demo.github.io/? Or is any additional config needed?

From https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/threat-prevention/set-up-file-blocking:

File Blocking Profiles allow you to identify specific file types that you want to want to block or monitor. For most traffic (including traffic on your internal network) you will want to block files that are known to carry threats or that have no real use case for upload/download. Currently, these include batch files, DLLs, Java class files, help files, Windows shortcuts (.lnk), and BitTorrent files.

@SteveSandersonMS I'm awaiting a meeting with our IT Administration Team that remotely manages NOD32 and it's configuration to find out what (if anything) they have changed/customised, as I've also received an automated email from our NOD32 system stating that I have may violated corporate security policy by downloading/installing untrusted software. I'll post back as/when I find out or have additional info.

I'm wondering if the .dlls could/would be blocked if they got packaged up into a .nupkg and unpacked/loaded by blazor after download ?

Currently, these include batch files, DLLs, Java class files, help files, Windows shortcuts (.lnk), and BitTorrent files.

That is what I'm saying... Regardless of the product, that is the _default_ list of file types that would be blocked by any IT administrator in regular (usually non-IT-based) company...

BTW, if there is someone from the WPF team that worked with .xap, they can clearly tell anyone what they faced when they released "WPF in a Browser" back in the day and faced _exactly_ same problem.

It took a while until _all_ the anti-virus software start to _trust_ on that extension.

I had the same issue. Tested the sample inside a corporate network. A DLL file was reported as being blocked. This basically makes it impossible to demo this to a colleague. Getting DLL files to be unblocked is probably a non-starter.

Looking at the official conventions page...
http://webassembly.github.io/spec/core/binary/conventions.html

The recommended extension for files containing WebAssembly modules in binary format is “.wasm” and the recommended Media Type is “application/wasm”.

So it would seem that the first thing to do is to rename the files to .wasm, and if they are still blocked, then the firewall needs to be unblocked.

I don't think that renaming the files to .wasm is a good idea. The DLLs are no Wasm modules, they are .NET assemblies which are (currently) interpreted by the Mono Wasm runtime (read more). Only the Mono runtime is a Wasm module. However, I also vote for renaming the DLLs to something else because of firewalls especially in enterprise scenarios.

Antivirus AVG version 18.1.3044 blocked the DLL files too when i tried to visit https://blazor-realworld.azurewebsites.net/

I don't think that renaming the files to .wasm is a good idea. The DLLs are no Wasm modules, they are .NET assemblies which are (currently) interpreted by the Mono Wasm runtime (read more). Only the Mono runtime is a Wasm module.

The problem is what that "something else" extension would be because none of the existing extensions apply (.NET MSIL payloads interpreted directly in the browser sandbox is a brand new concept in security) whereas wasm is already allowed by the corporate firewall.

The handling of .xap may not be a good reference from a security standpoint because it bypasses the browser security sandbox unlike wasm.

Yes, the DLL files contains MSIL so it is technically true, they are not strictly binary wasm. But they are named DLL because they are named after native Win32 DLLs even though they just share a fragment of the PE format and are mostly different internally anyway. Along the same lines, wasm is the "native" library format for Webassembly, and for the same reason that it made sense to name managed libraries DLL:s (even though they are nothing like native DLL:s internally), it can make sense to name them wasm. From a security perspective, DLL implies "local execution" whereas wasm implies "browser execution". To comply with the wasm format, perhaps the .NET assembly could be embedded as data to make it a valid wasm with the magic initial string and all.

The idea here is that there is an analogue: wasm is to MSIL what PE is to MSIL: a wrapper container format. Precendent:

https://docs.microsoft.com/en-us/dotnet/standard/assembly-format

The .NET binary format is based on the Windows PE file format. In fact, .NET class libraries are conformant Windows PEs, and appear on first glance to be Windows dynamic link libraries (DLLs) or application executables (EXEs). This is a very useful characteristic on Windows, where they can masquerade as native executable binaries and get some of the same treatment (for example, OS load, PE tools).

If the Blazor model does not play 100% well with existing firewalls it is almost a show stopper. It should flow through all firewalls effortlessly just like Javascript. If I was a firewall administrator, I am not sure if I would want to add a new white list entry for each new languages that has its own IL format.

If the Blazor model does not play 100% well with existing firewalls it is almost a show stopper.

@SteveSandersonMS sorry if you've answered this before, but do you envisage this being solvable?

Of course! We will change either the URLs or content format as needed.

it would be great if this could get prioritised for the next milestone. Would realy allay people's fears that it's a show-stopper due to potential corporate security blocks

@JonnyGibson As Steve mentioned earlier, we do plan to address this, but in the spirit of Blazor being an experiment project we're prioritizing work right now that is less well understood. We're pretty sure we know how to address this one.

Here's another example:

Maybe a solution would be to let the developer define the extension for an app until firewalls and AV add support in the whitelist for whatever extension is decided on.

Regarding my previous comment on letting the developer define the extension this would also allow developers to create apps with different extensions to test out the firewall and Antivirus behaviour.

@jonparker @torhovland it feels to me that as opposed to defining extensions which may or may not get blocked, we need to find a way that ensures its never blocked. No one is going to use a framework that is going to cause a web site to be blocked under some (quite likely) scenarios.

The idea to remove the extension seems reasonable and should be tried asap. I haven't seen any other issues raised which are as close as this is to being a showstopper.

The idea to remove the extension seems reasonable and should be tried asap.

In order for us to test any fix we need to be able to reproduce or at least investigate as many problematic environments as possible. To help us with that please continue to provide details on your environments where you run into issues with Blazor apps getting blocked. Thank you everyone who has already reported on this!

I haven't seen any other issues raised which are as close as this is to being a showstopper.

In the long run we're not too concerned about this issue. We're pretty confident that we will be able to handle this issue with some form of app packaging or app transformation. But we're holding off on designing a solution until we have more data on what the specific problems are.

WebSense is the tool my corporate network uses to control web access. I'm pretty sure that the issue blocking Blazor is just their explicit executable file download blocking.
https://www.websense.com/content/support/library/web/hosted/admin_guide/exten_block.aspx

Looks like AVG is blocking my blazor project. https://files.gitter.im/aspnet/Blazor/Oc8w/image.png

I can confirm I also had experience with AVG blocking my website. My friend couldn't access the website without disabling AVG. as far as I know he used the default antivirus settings.

DLL extension is non issue... With AOT compilation in the works, DLLs will not be distributed, as I understand DLLs are used for quicker dev loop. Don't spend time on this, get AOT working, that's the goal.

A well... #897 was a duplicate.

This was my error

maybe we can set the extension as a parameter in UpdateIndex where we would get it from the command line (default "dll") : https://github.com/aspnet/Blazor/blob/dev/src/Microsoft.AspNetCore.Blazor.Build/Core/IndexHtmlWriter.cs

If I send a PR on this, would it be considered ?

Please fix this issue, it is the only item blocking me from testing this in the enterprise.

Quick fix suggestion if you are using IIS with the rewrite url module :

• you can change in the output all ".*.dll files by .wasmnet or anything. his will edit the content of the script tag (https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/creating-outbound-rules-for-url-rewrite-module)
• rewrite this extension to dll so the good files will be send to the browser (or rename the dll files after deploying)

you might be able to do this with .net core https://docs.microsoft.com/fr-fr/aspnet/core/fundamentals/url-rewriting?view=aspnetcore-2.1&tabs=aspnetcore2x

Just another idea: I note that most of these firewall and security products don't block .zip files. In fact, many times when trying to download a .dll file where I am blocked on some corporate network, I notice a .zip version of the same file will almost always pass the blocking.

So we could simply package MyLib.dll as MyLib.zip (containing a single MyLib.dll file inside the zip). The problem is that the browser will natively be faster decompressing the files contents compared to if it was WASM/MONO using some .NET assembly to unzip the compressed archive's content. There would be at least a 2x-3x slowdown for the unzip.

But there is a solution: We could package the MyLib.dll file as MyLib.zip with ZERO compression used, then leave it up to the web server to compress the file (using whatever compression formats the client browser supported when requesting the file). When the browser downloads that file, it will natively decompress the received content, before it hits Mono/WebAssembly. So the Mono runtime would then just need to unpack the .zip file (which at this point is the original uncompressed zip archive).

I hope nobody is confused by the above. I am just suggesting that we use .zip as an uncompressed container format; then let the web browser and web server handle compression and decompression the way they do normally for any requested file. To give a concrete example:

1. 2 MB mscorlib.dll gets .zipped into 2 MB mscorlib.zip (note we set compression to NONE).
2. Web browser requests mscorlib.zip (sending usual Accept-Encoding headers with compression methods supported).
3. Web server compresses content of mscorlib.zip down to 700 MB and sends that to server, so the package size would be the same as it is today)
4. Web browser (Chrome or Edge, etc) decompresses content natively, and the Mono runtime would receive the original 2 MB mscorlib.zip file, which WASM Mono can unpack to the original .dll really fast because there isn't any internal compression used on that original zip archive.

So that is just another suggestion to include in the bucket. My thoughts on other ideas suggested:

• I would hope it would be enough just to remove the extension, as in MyLib.dll becomes MyLib or the earlier MyLib_dll suggestion.
• I also agree it should be possible to "package" the assembly as data inside a .wasm file (but still internally in IL format) in the same way .NET assemblies use the PE format and were given .dll as an extension. So we could have a MyLib.wasm that internally stored the IL as data. The only disadvantage I see here is when we have real AOT compilation it might be hard to visually tell if a .wasm file contained IL or Natively (WASM) compiled code.

.dll would be the proper extension and should be kept as default. Hiding the intention of the file by changing the extension to .zip isn't an optimal solution, since it produces confusion. It would probably be better to use no extension at all and name the file like somedllname_v1_0_0_4321_ab5e8d5b97d141aca3c54776e82d2355
(that is project name, file version and an SHA-256 hash)

A bigger problem is, that current AV scanners (heuristically) detect routines which fetch additional code. There is no real solution to that problem until AV vendors make adaptions to support .wasm. So better contact the AV vendors and report as a bug, such that they can fix it.

I 100% agree with @MovGP0. AV vendors have to update their software. They use different algorithms to detect malicious code and those algorithms have to be smart enough to block viruses and allow legitimate software. I believe that every modern AV scanner checks content of every archive, zip, 7z, rar, etc. Changing file name extension or pseudo-packing is not a long term solution.

It just seems silly that this is an issue because the blocking is due to legacy reasons. There are two scenarios with Blazor for DLLs:

1. IL code running interpreted in a browser: In this case the IL code in the DLL is just raw DATA, and no more threat than a JPG or XML file the browser is processing. This is because the downloaded IL is being completely interpreted. The security product has no more business with this than it does with whatever GIF, XML or TXT file a website is processing.

or (in the future)

1. IL code compiled AOT to .wasm. In this case the IL code would generate .WASM and the only issue should be how these security products handle .wasm files.

Another point about “packing” is that this is exactly what many javascript frameworks already do to reduce requests to the server: have some server side script dynamically combining multiple separate script filed into a single file. I would personally love to see some intelligent server side handler that could dynamically combine 20 small (5k) DLLs to reduce initial server requests and let me as a developer optionally have some control over that during page load.

But I think the Blazor team has our feedback now and will do whatever is sensible and/or provide options.

I will point out that a view that we must wait until everyone updates their security products doesn’t work because it isn’t just products it is existing large companies that won’t realistically make configuration changes to their network infrastructure. This will really hurt Blazor use because it is not just about AV scanners it is about trying to tell staff within an IT department of large company like News Corporation or Bhp Billiton to make network configuration changes. Culture is changing, but there are still many staff in those departments that simply wouldn’t care (or would actively smile) if this caused Blazor issues ☹.

• I believe that every modern AV scanner checks content of every archive, zip, 7z, rar, etc.
  My personal experience over the last decade is that when in .zip form everything is usually fine. Things are usually blocked if the files are .exe or .dll. Within a zip archive most products would only block the zip file if they detect an actual known signature of malware within the zip archive (not just because there is a .dll inside). But I acknowledge every product is different so there are not any guarantees here.
  From: Andrzej-W notifications@github.com
  Sent: Wednesday, 6 June 2018 5:38 AM
  To: aspnet/Blazor Blazor@noreply.github.com
  Cc: jiggyswift mail@davtaylor.com; Comment comment@noreply.github.com
  Subject: Re: [aspnet/Blazor] Consider changing URLs of .NET assemblies not to end with .dll (#172)

I 100% agree with @MovGP0https://github.com/MovGP0. AV vendors have to update their software. They use different algorithms to detect malicious code and those algorithms have to be smart enough to block viruses and allow legitimate software. I believe that every modern AV scanner checks content of every archive, zip, 7z, rar, etc. Changing file name extension or pseudo-packing is not a long term solution.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/aspnet/Blazor/issues/172#issuecomment-394834055, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AmF6aIkiXWAVe282A0YSh_a7bgmGPGN7ks5t5t4OgaJpZM4SUpej.

I had two people from the Corporate Security Team come to my desk after I browsed the the mono wasm example site, which downloads a hello.exe. I think it was picked up by "Symantec Endpoint Protection".

Thanks Harry. Did they give you time to pack everything into a box before walking you out the door? Best story yet.

From: Harry McIntyre notifications@github.com
Sent: Thursday, 7 June 2018 8:36 PM
To: aspnet/Blazor Blazor@noreply.github.com
Cc: jiggyswift mail@davtaylor.com; Comment comment@noreply.github.com
Subject: Re: [aspnet/Blazor] Consider changing URLs of .NET assemblies not to end with .dll (#172)

I had two people from the Corporate Security Team come to my desk after I browsed the the mono wasm example sitehttps://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.hipbyte.com%2F%257Elrz%2Fmono-wasm-hello&data=02%7C01%7C%7Cf21af207f881447e8d5d08d5cc627621%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636639645608861860&sdata=Cp9wUKXElAX4z39zarw0DQOlhHo3ZY0MtSRdz8j5YDw%3D&reserved=0, which downloads a hello.exe. I think it was picked up by "Symantec Endpoint Protection".

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Faspnet%2FBlazor%2Fissues%2F172%23issuecomment-395374377&data=02%7C01%7C%7Cf21af207f881447e8d5d08d5cc627621%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636639645609018105&sdata=A9rl39HzRP7w9mzRkqPKrG4zsHJKkVIy2jwJ0e9nc3g%3D&reserved=0, or mute the threadhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAmF6aG9lvmy2g93BQQmI-5mbrGICanCxks5t6QIPgaJpZM4SUpej&data=02%7C01%7C%7Cf21af207f881447e8d5d08d5cc627621%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636639645609018105&sdata=yZhLQXXqqp0hLEtD3mTowdoI4EpBu5qNNR0UI4tZDm8%3D&reserved=0.

Maybe useful:

From https://www.cisco.com/c/en/us/td/docs/security/firepower/623/configuration/guide/fpmc-config-guide-v623/file_policies_and_advanced_malware_protection.html

The system can inspect up to three levels of nested files beneath the outermost archive file (level 0) if the file is an archive (such as .zip or .rar archive files). You can inspect archive files as large as the Maximum file size to store advanced access control setting.
If any individual file matches a file rule with a block action, the system blocks the entire archive, not just the individual file. The system can also block archives that exceed a specified level of nesting, or whose contents are encrypted or otherwise cannot be inspected.

Another link (scroll to "Files types feature"):
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk105318&js_peid=P-14d3e69bf07-10000

I found a workaround described here : https://remibou.github.io/Change-Blazor-DLL-extension-with-ASPNET-Core/. It might not help for every case and AV but it's a starting point.

@RemiBou man... that is awesome :) Good catch on use URLRewrite for that! 👍

On the topic of the dll extension replacement i would like to push for the wasm extension (even if not tecnically correct) because github pages, cloudflare and probably most CDNs are already handling the compression for "application/wasm" but not for "application/octet-stream" so a default Blazor app weights about 3.2 MB having only mono.wasm compressed with brotli. In the end Blazor libraries are already going to be wasm anyway when the AOT compilation will be in place, aren't they?

I just tested @RemiBou trick using wasm extension and renaming the dlls before pushing them to gh-pages and now a cold refresh amounts to 1.9 MB as it should be: great! Thanks @RemiBou!!

But my Avast antivirus initially went crazy because all those fake wasm files were infected with DRep and I got the same alert window as @jorisvergeer . After a quick search I think that the problem could be solved having the fake wasm libraries downloaded from a site with a better reputation than my recently created subdomain but I'm just guessing now.

For an example of how an client side blazor app fails from inside a corporation, see the attached PDF file. This is a frustrating problem from a developer's point of view as we are at the mercy of something that is outside our control.

It would be awesome if we could try pre-compiling the dlls to wasm files and then be able to download them instead. (hopefully that would work)

403forbidden.pdf

The 403 forbidden message in the previous post was generated by our zscaler firewall.

What is the best way to bring visibility and priority to this issue so it gets considered in a future sprint?

@rynowak @SteveSandersonMS @mkArtakMSFT We need to make sure we have a solution for this, so moving into the blazor-wasm milestone.

I have created a doc describing the solution I use right now to work around the dlls being blocked by zScaler.

https://github.com/jucchytil/CSBNotes/blob/master/Notes.md

I suspect we may need to consider a similar solution for WASM files as there is the possibility firewalls manufacturers may take a while to accept wasm files as being safe over the next couple of years.

I am really looking forward for the PublishSingleFile/PublishTrimmed/TargetFramework=wasm so we only have a single relatively small file to manage in the service worker.

Your thoughts?

Thanks Dan!
I am grateful this is getting some attention.
I posted my interim solution to https://github.com/aspnet/AspNetCore/issues/5477
Hopefully it can help in some way.
Joe

From: Daniel Roth notifications@github.com
Sent: Friday, October 11, 2019 10:33 AM
To: aspnet/AspNetCore AspNetCore@noreply.github.com
Cc: jucchytil juchytil@Outlook.com; Comment comment@noreply.github.com
Subject: Re: [aspnet/AspNetCore] Consider changing URLs of .NET assemblies not to end with .dll (#5477)

@rynowakhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frynowak&data=02%7C01%7C%7Cecf83fca357f4abe690d08d74e604c75%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637064047810603291&sdata=N5o8HJ7%2FM1UInuoFp1HXbY9AqDhM8BCm%2F0IGZujyqqI%3D&reserved=0 @SteveSandersonMShttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSteveSandersonMS&data=02%7C01%7C%7Cecf83fca357f4abe690d08d74e604c75%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637064047810613296&sdata=vDuSWWEJ0CGf7ex7TStTMrHH1E27V5eza%2FMJKIkr%2BeY%3D&reserved=0 @mkArtakMSFThttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FmkArtakMSFT&data=02%7C01%7C%7Cecf83fca357f4abe690d08d74e604c75%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637064047810623307&sdata=ltzBUDC4c8o9kPvFmBlIOHN1B%2BUI2Fj%2FspG4WCIo%2BD8%3D&reserved=0 We need to make sure we have a solution for this, so moving into the blazor-wasm milestone.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Faspnet%2FAspNetCore%2Fissues%2F5477%3Femail_source%3Dnotifications%26email_token%3DAEBYRE4UUUJDL3KHNPOYYJ3QOCMCVA5CNFSM4GK4V5L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBALS2Y%23issuecomment-541112683&data=02%7C01%7C%7Cecf83fca357f4abe690d08d74e604c75%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637064047810633312&sdata=qxqf5LstFcAUsEgSImIxMMOw33sNOgku09qw%2FJp3Z18%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEBYRE2MQUF65CHXQD54OWDQOCMCVANCNFSM4GK4V5LQ&data=02%7C01%7C%7Cecf83fca357f4abe690d08d74e604c75%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637064047810643323&sdata=yx154tNWkGvXlXbVJNjvswed9hG0zr91HFqIhMVLCfo%3D&reserved=0.

Just following up on a request from Daniel Roth on his blog, who asked me to post the name of my web hosting provider here, so you can test this issue. Blog comment can be found here:- https://devblogs.microsoft.com/aspnet/asp-net-core-and-blazor-updates-in-net-core-3-0/#comment-955

The hosting provider in question is infinityfree.net. They’re free, so it’ll be easy to try out!

Basically, when uploading the site, their server will delete around half of the DLLs from the _framework\bin\ folder. I originally thought something had gone wrong and repeatedly tried to upload the missing files. Eventually they seemed to “stick”, as though their server gave up virus checking the new files, and a day later are still there (although perhaps they’ll eventually be swept up).

Anyway, please add my vote for a suitable solution such as renaming the DLLs.

@andyste1 Thanks for the info. Did you check and confirm that if the files were renamed, they do not get deleted? If the hosting company is doing this based on content rather than name, then renaming wouldn’t necessarily be a solution.

Renaming may not help much - woraround has already available to achieve this.
For me, the problem is the PE format of the file - the anti-virus program, Sophos, will block the files every I renamed it, as it did scan the content of the file as well. Luckily Sophos allow dowloading DLL (PE format) files via HTTPS (not HTTP).

@lertoo we are discussing potentially removing the PE metadata from the assemblies to reduce size, but it may also help with this issue.

Norton antivirus version of this issue: https://forums.asp.net/t/2161027.aspx

It is very likely not only the file extension, but the file header as well to cause an issue with some paranoiac software. Obfuscation will not help when the issue is with the header, except the JS which is starting the Blazor VM is not manually replacing them in-memory somehow, but it is a long shot.

My current workaround is to provide a Base64 encoded version of each DLL in my CI/CD pipeline, using a service worker to detect the 403 from the firewall for the DLL, downloading the Base64 version of the DLL text file, and converting Base64 back to DLL in the service worker before caching it in the browser.

It would be curious to see if the problem goes away if we could just convert the DLLs to WASM files as the WASM file seems to get through OK for me, but it may not be true for all Firewalls.

Another Blazor WebAssembly false positive:

Ive been waiting since early 2018 for this issue to be resolved :) i love/loved blazor, but this one seemed like such a potential show stopper, if the dlls couldn't be changed

@JonnyGibson Thank you for your patience! We are working to have some sort of resolution to this issue for the upcoming release in May of this year.

This is pretty long issue so I've tried to summarize all this in here:

Antivirus

• NOD32 (ESET)
• AVG v. 18.1.3044 (+3)
• Web traffic scanning
• Avast (+3)
• Symantec Endpoint Protection
• zScaler

Rename proposals

• .blazor (+35)
• .bin (+3)
• .lib
• .ilasm (+6)
• .net (+14)
• .wasm (-8)
• [custom] (+1)
• [None]

Workaround people use

• Rename extension
• BASE64 encode DLLs

General notes

• .DLLs and .EXEs are extensions many enterprises block on firewall level, as a policy.
• There have been reports of renamed extensions also being reported by antivirus software

@mkArtak
You may also want to include zScaler somewhere in your summary as that is what was blocking my downloads.

One approach to test is to convert all executables to wasm files as I don't remember zScaler having troubles with them.

I've temporarily move to Angular until client side blazor works out these issues and has better initial download times.

I've poured a lot of time in trying to get client side blazor to work and decided to wait until the platform has matured some more.
https://github.com/jucchytil/CSBNotes/blob/master/Notes.md

@javiercn let's track the file extension rename work here and I will file a separate issue to follow-up with the Anti-virus providers regarding this.

ACTION REQUIED

🎫
I've just created a new issue where we will be trying to collect all the specific software blocking Blazor WASM applications. Please provide information specific to your case as described in here: https://github.com/dotnet/aspnetcore/issues/19552

On a side note, CDNs like github pages and cloudflare are compressing the assets with a wasm extension out of the box while they're serving an uncompressed version for the dll files. If I remember correctly Azure CDN should behave in the same way.

We experienced this today. Having the restriction on DLL downloading lifted isn't going to be an option. Not only for us, but our customers are very unlikely to remove that restriction too - so we really need a fix for this otherwise our Blazor project is dead in the water (employer is unwilling to use server-side).

I believe our firewall is a Palo Alto.

@mrpmorris can you put the details in https://github.com/dotnet/aspnetcore/issues/19552 as this is where we are collecting them so that we can engage vendors.

@mrpmorris has changing the extension solved the issue in your scenario?

Hi @javiercn

I've just updated that issue. It seems that switching to https worked for us, which makes sense. We can't be sure our clients are willing to have the same exception though.

I will be happy to check the renaming option. Do you have a link to instructions on how to get Blazor to work with .wasm extensions or something else? At the moment I am just right-clicking my webserver project and choosing Publish straight to an Azure Web App.

@mrpmorris You can check the instructions here
https://github.com/dotnet/aspnetcore/pull/19558#issuecomment-594461263

@mrpmorris Please note that those instructions only apply to our latest 3.2.0-preview2 builds and upgrading from 3.2.0-preview1 will take a bit of work using steps that we haven't published yet. You might want to wait until we release later this month.

@danroth27 I dont think you published preview2 yet... :)

You can try this with the nightly builds following the instructions here if you choose to do.

I would recommend you clear your nuget package caches before and after if you choose to do that. Take into account that clearing the caches will impact the entire machine (all apps in that machine)

I'll wait for the p2 build to be released and then try it out. Thanks!

@mrpmorris 3.2 Preview 2 is now available! Do the steps suggested in https://github.com/dotnet/aspnetcore/pull/19558#issuecomment-594461263 for renaming the files work for you?

Hi folks!

In the recent Blazor WebAssembly 3.2 Preview 2 release we made some changes to make it easier to rename the .dll files in your app as a way to address proxies/firewalls/antivirus software interfering with Blazor WebAssembly apps. We'd like folks who are hitting this issue to try out the steps below on the published output of your Blazor WebAssembly apps (standalone or ASP.NET Core hosted) and see if it helps:

Windows

• Open a PowerShell prompt in the wwwroot directory of your published output (for example, in yourapp\bin\Release\netstandard2.1\publish\wwwroot
• Execute the following two lines:

dir .\_framework\_bin | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content .\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content .\_framework\blazor.boot.json

Linux / macOS

• Open a terminal in the wwwroot directory of your published output (for example, in yourapp/bin/Release/netstandard2.1/publish/wwwroot
• Execute the following two lines:

for f in _framework/_bin/*; do mv "$f" "`echo $f | sed -e 's/\.dll\b/.bin/g'`"; done
sed -i 's/\.dll"/.bin"/g' _framework/blazor.boot.json

Please give these steps a try and let us know how it goes. If you still run into problems please let us know! We have some other ideas of things to try if necessary.

Thanks!

That worked for me. Although I had to adjust my publish step on Azure DevOps and deactivate that it generates a zip at the end.

In my case:

- task: DotNetCoreCLI@2
  displayName: 'dotnet publish'
  inputs:
    command: 'publish'
    publishWebProjects: false
    zipAfterPublish: false
    projects: |
      **/ApplySupportTool.Server.csproj
    arguments: '--configuration $(buildconfiguration)  --output $(Build.ArtifactStagingDirectory)'

- task: PowerShell@2
  displayName: Change Outputname
  inputs:
    targetType: 'inline'
    workingDirectory: $(Build.ArtifactStagingDirectory)\ApplySupportTool.Server\wwwroot
    script: |
         dir .\_framework\_bin | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
         ((Get-Content .\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content .\_framework\blazor.boot.json

@NPadrutt It worked in what sense? In the sense that you conclusively observed your site was not working before (due to some kind of antivirus or firewall), and the change of URLs fixed this? If that is the case, would you please be able to post details of what antivirus/firewall/etc was causing problems for you before at https://github.com/dotnet/aspnetcore/issues/19552? Thanks!

@SteveSandersonMS well, I had previously the work around via the rewriter in place. After the upgrade to the 3.2 preview 2 that one didn't work anymore and the application was blocked again. With the above it is working again.

Unfortunately I can't tell you what firewall we have in our network and I don't think that the AntiVirus (McAffee) has an impact here, since working locally worked without problems.

Someone at my office has tested positive for COVID-19, so it looks like my office will be closed for a couple of weeks - which means I won't be accessing files through their firewall. Sorry.

@mrpmorris No problem. Stay safe!

Hi folks!

In the recent Blazor WebAssembly 3.2 Preview 2 release we made some changes to make it easier to rename the .dll files in your app as a way to address proxies/firewalls/antivirus software interfering with Blazor WebAssembly apps. We'd like folks who are hitting this issue to try out the steps below on the _published output_ of your Blazor WebAssembly apps (standalone or ASP.NET Core hosted) and see if it helps:

@danroth27

I ran the script (I develop on Windows, but I deploy from a Linux environment to another Linux environment, so I used the Linux script provided) and it deployed with the new names, and when loading the page it seems to be loading the files with the new extensions fine, and the app works. In our case, Avast no longer flags the app and no longer blocks downloads.

Due to the pandemic situation, it'll be a bit before we check the corporate firewall situation.

This is a simple enough step to add to the build and appears to have no downside, so we will start using it.

Thanks!

@danroth27 is this going to be the default at some point so we don't need to do this step? Is there really any reason to not just move to .bin or no filetype as the default instead of requiring everyone to do this if there is a general issue with .dll file type?

Is there any chance that a virus checker will check the file even if it isn't ".dll" to see if it is a dll file?

@danroth27 @SteveSandersonMS
I got lots of errors in browser's console related to integrity failure or file not found:

_framework/_bin/Blazored.LocalStorage.dll:1 Failed to load resource: the server responded with a status of 404 ()
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
Failed to find a valid digest in the 'integrity' attribute for resource '<URL>' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked.
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/BlazorStrap.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.AspNetCore.Blazor.HttpClient.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.AspNetCore.Components.dll:1 Failed to load resource: the server responded with a status of 404 ()
_framework/_bin/Microsoft.AspNetCore.Components.Authorization.dll:1 Failed to load resource: the server responded with a status of 404 ()
_framework/_bin/Microsoft.AspNetCore.Components.WebAssembly.Authentication.dll:1 Failed to load resource: the server responded with a status of 404 ()
_framework/_bin/Microsoft.AspNetCore.Authorization.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.AspNetCore.Components.Web.dll:1 Failed to load resource: the server responded with a status of 404 ()
_framework/_bin/Microsoft.AspNetCore.Components.Forms.dll:1 Failed to load resource: the server responded with a status of 404 ()
_framework/_bin/Microsoft.AspNetCore.Components.WebAssembly.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
admin:1 Unknown error occurred while trying to verify integrity.
admin:1 Unknown error occurred while trying to verify integrity.
admin:1 Unknown error occurred while trying to verify integrity.
admin:1 Unknown error occurred while trying to verify integrity.
admin:1 Unknown error occurred while trying to verify integrity.
A cookie associated with a cross-site resource at <URL> was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at <URL> and <URL>.
A cookie associated with a cross-site resource at <URL> was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at <URL> and <URL>.
A cookie associated with a cross-site resource at <URL> was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at <URL> and <URL>.
A cookie associated with a cross-site resource at <URL> was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at <URL> and <URL>.
A cookie associated with a cross-site resource at <URL> was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at <URL> and <URL>.
A cookie associated with a cross-site resource at <URL> was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at <URL> and <URL>.
blazor.webassembly.js:1 Error: Failed to start platform. Reason: TypeError: Failed to fetch
    at blazor.webassembly.js:1
    at blazor.webassembly.js:1
    at Object.throw (blazor.webassembly.js:1)
    at u (blazor.webassembly.js:1)
d.printErr @ blazor.webassembly.js:1
_framework/_bin/Microsoft.AspNetCore.Metadata.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.Bcl.HashCode.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.CSharp.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.EntityFrameworkCore.Abstractions.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.Extensions.Caching.Abstractions.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.EntityFrameworkCore.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.EntityFrameworkCore.Relational.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.Extensions.Caching.Memory.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.Extensions.Configuration.Abstractions.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.Extensions.Configuration.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.Extensions.Configuration.Json.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.Extensions.DependencyInjection.Abstractions.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.Extensions.DependencyInjection.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.Extensions.Identity.Core.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.Extensions.Identity.Stores.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.Extensions.Logging.Abstractions.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.Extensions.Logging.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.Extensions.Options.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.Extensions.Primitives.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Microsoft.JSInterop.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Mono.Security.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/MovingPicturesEvents.Core.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/MovingPicturesEvents.Services.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/mscorlib.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/MovingPicturesEvents.Web.Client.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/netstandard.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/Radzen.Blazor.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.Collections.Immutable.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.ComponentModel.DataAnnotations.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.Core.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.Data.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.Diagnostics.DiagnosticSource.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.Linq.Dynamic.Core.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.Net.Http.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.Net.Http.Json.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.Numerics.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.Runtime.CompilerServices.Unsafe.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.Text.Encodings.Web.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.Text.Json.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.Transactions.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.Xml.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/System.Xml.Linq.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/WebAssembly.Bindings.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.
_framework/_bin/WebAssembly.Net.Http.dll:1 Failed to load resource: the server responded with a status of 404 ()
admin:1 Unknown error occurred while trying to verify integrity.

I tried the steps @danroth27 mentioned both on Windows and on a Linux Docker container with the same results.

Using 3.2 Preview 4.

@radderz This issue doesn't appear to affect all environments - it's specific to certain environments and is often policy based. If we switch to a different file extension there is no guarantee that this will work for everyone. So, instead of changing the default for everyone, we are going ahead with the plan where customers that hit this issue can control the file extensions themselves using the technique provided above.

It is certainly possible that antivirus software/proxies/firewalls may do a deeper inspection of the files than just look at the file extension. So far we haven't heard of anyone getting blocked by this yet. If this becomes a problem, we will at other mitigations.

@mihaimyh Looks like you might have a misconfigured content security policy?

@mihaimyh Looks like you might have a misconfigured content security policy?

@danroth27 Can you, please, be more explicit? What security policy are you talking about? I got those errors even on dev environment where I believe there is no security policy implemented.

@mihaimyh Sorry, I think I mixed up content security policy with subresource integrity. It looks like the browser is trying to enforce that the hashes of downloaded assets match hashes specified in markup via the integrity attribute, but the integrity attribute is missing. This could also be related to how Blazor downloads and caches the app resources, which uses a similar hash based strategy to verify if files have changed.

@mihaimyh Sorry, I think I mixed up content security policy with subresource integrity. It looks like the browser is trying to enforce that the hashes of downloaded assets match hashes specified in markup via the integrity attribute, but the integrity attribute is missing. This could also be related to how Blazor downloads and caches the app resources, which uses a similar hash based strategy to verify if files have changed.

@danroth27 Ok, and I believe I can bypass integrity checking by adding

<BlazorCacheBootResources>false</BlazorCacheBootResources>

to my .csproj files but I still got 404 event with integrity checking disabled.

@mihaimyh If you can reproduce this reliably, I would suggest opening up a new issue for this problem, as it doesn't appear to be related to the file extensions issue. That will make it easier to engage the right folks.

Make sure that you add something like this in your "dll rename" script

# Remove compressed versions of blazor.boot.json because it still looks for .dll files
Remove-Item ".\_framework\blazor.boot.json.gz"
Remove-Item ".\_framework\blazor.boot.json.br"

Most of the time the precompressed blazor.boot.json will be downloaded instead of the "fixed" blazor.boot.json making requests to the ".dll" files instead of the ".bin" files causing the integrity issue.

So you have to either remove the compressed json files or recompress the blazor.boot.json but I don't think it is worth it to go through that hassle.

Hopefully one day this could all be handled by the framework with a flag in the csproj, e.g.

<BlazorBinariesExtension>.bin</BlazorBinariesExtension>

Hi folks. At this point we've documented the strategy we recommend for changing the file extension for the published .NET assemblies using scripts. I think @stavroskasidis's suggestion is still a good one to provide a simple built-in way to do this, so I've opened https://github.com/dotnet/aspnetcore/issues/21489 to track the suggestion. At this point I think we're ready to close this issue. Thanks everyone for the detailed feedback provided!

From what I can see the rename from .dll to .bin must be done also in wwwroot/service-worker-assets.js and remove or re-compress wwwroot/service-worker-assets.js.br and wwwroot/service-worker-assets.js.gz, otherwise there are integrity issues in browser's console.