Consider changing URLs of .NET assemblies not to end with .dll

[Rast1234]

I wanted to see the demo at https://blazor-demo.github.io/ and my corporate firewall blocked MicroApp.dll, while other dlls downloaded successfully. Since a lot of software is paranoid about downloading/transferring windows binaries, maybe it's worth obfuscating them a bit? Or, at least, renaming?

[SteveSandersonMS]

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.

[galvesribeiro]

@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.

[joeizy]

@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 :)

[galvesribeiro]

@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...

[wilka]

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" :)

[Manuel-S]

How about simply .bin?

[galvesribeiro]

I like .bin or .blazor as well.

[joeizy]

+1 “.bin”

[grahamehorner]

.lib or .bin or .ilasm ?

[SteveSandersonMS]

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?

[galvesribeiro]

@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.

[miroslavp]

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.

[galvesribeiro]

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...

[miroslavp]

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.