Hello @Rick,

if you can think of a good example or use case please chime in with a comment I would love to elaborate this point here.

Reading David's tweet above, I believe, when you are building a modular application in ASP.NET Core, where multiple modules need to "inject" something that needs to be retrieved later by a certain "Core" module (assuming you need to collect settings from all modules in the app). Then, by using services.Configure() multiple times (each module will be using it), then this way, the ASP.NET Core Framework would collect all instances from all modules and make them available for you.

For instance, you might define a Dictionary read-only property inside a custom Options class and then each module would read that dictionary and append to it some settings or whatever the business logic you need.

The end result is that the custom Options class having its read-only dictionary property, collecting all values that were added by all modules.

That's how I could think of it!

What do you think?

.NET Conf 2018 isn't exactly filling me with confidence. Daniel Roth tells us we're moving from 0.5.0 experimental to 0.6.0 experimental with monthly increments, but meanwhile expect to see Razor Components as part of a .NET Core 3.0 preview early 2019 - the new name for server side Blazor with SignalR to do DOMdiff and no Mono.

The whole thing raises all sorts of questions - why do you need Razor if all you want to do is marshal DOMdiff over SignalR? Why is Blazor taking so long to get out the stable? Why are MS unsure about Mono? Have MS really got it about the UI being the way forwards to get past mobile?

I just don't buy that it'll be painless moving stuff from server side to client.

Thank you for solving this problem, in .NET 2.0 there is no class System.Net.WebUtility, and your method helped. We used your information in our note. Sincerely, the editor-in-chief of the site tolik-punkoff.com

I went ahead and made this extension method to cater for both IOptions and its concrete setting (POCO)

You can work around the constructor injection issue by implementing IOptions:

	public class S3Configuration : IOptions<S3Configuration>
	{
		public string BucketName { get; set; }
		// etc.

		[JsonIgnore]
		public S3Configuration Value => this;
	}

This lets you do a new MyController(new S3Configuration()) in your tests, although it's still messy with DI.

Thank you for the write up on binding configuration to an object. I was handling parsing IConfiguration manually until my app began to grow and become more complex. Having been aware of binding, I came looking specifically for an example of how to do so and found your page. I was hoping to see an example of binding a collection property in my config object with an array in my config file. I will try it now and see what happens. Thanks for your example to get me to the point I need to try this!

@Mani - yes, the Nuget Packaging happens automatically if you have a multi-targeted project set <GeneratePackageOnBuild>true</GeneratePackageOnBuild> in the project file. It'll automatically create a Nuget package for all the targets you include in the project as described here.

Rick,

Thanks for a great article! I have a dotnet standard 2.0 class library that will be shared between core & 4.6.1 applications. Have you setup a VSTS build to build, publish & nuget pack for both the targeted frameworks?

Thanks! Mani

@Pablo, thanks for the list and the additional Unicode hack 'example' 😄. I've updated the code above to handle that scenario as well as well as updated the text to point at HtmlSanitizer for a more robust solution when required.

Your antiXSS code is basic (I know, you have said it) and can be fooled with little effort.

For example, using Unicode: Click me

A good resource to check is https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

I would use only a white list aproach.

Check this library https://github.com/mganss/HtmlSanitizer

One remark about performance of dotnet core in WSL vs. "bare-metal" Windows 10:

The dotnet core linux interpreter (when running inside the WSL) is indeed horribly slow, but if you build your application with the -r switch, you get a compiled executable, which runs comparably fast on WSL and Windows 10. List of RIDs: https://docs.microsoft.com/en-us/dotnet/core/rid-catalog

dotnet build -r linux-x64

dotnet build -r win10-x64

you can even cross-compile like this, and create an EXE using dotnet core in WSL that is executable in windows.

best regards, Dennis

Hey there, Thanks for the ideas and starter code. People seem to be moaning and whining because this does not meet need x that they have. Instead of understanding that needs differ and that if it gives you even a fraction of an insight, then you have gained, for free. I for one, would not like a multilayered obtuse project that had little educational value, so I am glad it's still legible. Think a bit of those that are still learning and that require simplicity over completeness. Thanks a lot OP and if I get it into a CI type rest web service, with many alterations of course, then I will let you know. No FREE LUNCH B:TCHIZ!

THANK YOU! I just started using the CertifyTheWeb.com app to add SSL for three IIS based sites. It is a breeze! Just what I needed.

That's why it's important to have a Content Security Policy in place.

https://github.com/mganss/HtmlSanitizer library has noticeable unit tests far beyond the <script> tag.

As the post says: "The AppId is a hardcoded value that never changes". I presume it's specific to HttpHandler.

Hi Rick, Thanks for the example, works great as always. Just a little question how can i change the <h:Security></h:Security> prefix to wsse:Security</wsse:Security> ?

Thanks in advance.

Great article, as usual - and still applicable 5 years after it was published! I would just add one comment to the article - to keep the service from exiting (when -fakeservice argument is set), the Output Type of the project under Application tab project properties should be set to Console Application.

Hello, I used this to get vanilla-tilt.js and paralax.js and works fine, but when I change route stop working

import * as Parallax from 'parallax-js'; import * as VanillaTilt from 'vanilla-tilt';

export class HomeComponent implements OnInit, AfterContentInit {

constructor()

ngAfterContentInit() { const scene= document.getElementById('scene'); const parallaxInstance= new Parallax(scene,{relativeInput:true,hoverOnly:true}); VanillaTilt.init(document.querySelector(".tilt"), ) } }

hi，where is the “App ID”？ I can‘t find it！

netsh http add sslcert ipport=0.0.0.0:8082
           **appid={12345678-db90-4b66-8b01-88f7af2e36bf} **
           certhash=d37b844594e5c23702ef4e6bd17719a079b9bdf

I'm not sure that Throttle() is working properly. Unless my understanding of how it's supposed to work is incorrect. timerStarted is reset on every call. So, effectively, it currently (incorrectly) runs like this:

// assuming it's called once every 100ms
[0ms]	.Throttle(1000, ...) { timer = new timer(interval = 1000), timerStarted = now}
[100ms]	.Throttle(1000, ...) { timer = new timer(interval = 900), timerStarted = now}
[200ms]	.Throttle(1000, ...) { timer = new timer(interval = 900), timerStarted = now}
[300ms]	.Throttle(1000, ...) { timer = new timer(interval = 900), timerStarted = now}
...
// So the action will only be invoked 900ms after the last attempt, 
// instead of once every 1000ms. So, it's just Debounce, essentially.

Here's my modified implementation, which I believe is correct:

// ...

// renamed timerStarted to timerReset

// ...

public void Throttle(int interval, Action<object> action,
        object param = null,
        DispatcherPriority priority = DispatcherPriority.ApplicationIdle,
        Dispatcher disp = null)
    {
        // kill pending timer and pending ticks
        timer?.Stop();
        timer = null;

        if (disp == null)
            disp = Dispatcher.CurrentDispatcher;

        var curTime = DateTime.UtcNow;

        // if timeout is not up yet - adjust timeout to fire 
        // with potentially new Action parameters           
        if (curTime.Subtract(timerStarted).TotalMilliseconds < interval)
            interval -= (int) curTime.Subtract(timerStarted).TotalMilliseconds;
        else
            timerReset = curTime;

        timer = new DispatcherTimer(TimeSpan.FromMilliseconds(interval), priority, (s, e) =>
        {
            if (timer == null)
                return;

            timer?.Stop();
            timer = null;
            action.Invoke(param);
            timerReset = curTime;
        }, disp);

        timer.Start();            
    }

now, it runs like this:

[0ms]	.Throttle(1000, ...) { timer = new timer(interval = 1000), timerStarted = now}
[100ms]	.Throttle(1000, ...) { timer = new timer(interval = 900), timerStarted = now}
[200ms]	.Throttle(1000, ...) { timer = new timer(interval = 800), timerStarted = now}
[300ms]	.Throttle(1000, ...) { timer = new timer(interval = 700), timerStarted = now}

You're a lifesaver! Thanks for taking the time to document this.

Thanks for the in depth review. Our experience with Blazor to date is refreshing w.r.t. dealing with the ReactJS/JS ecosystem. Startup times must be solved, but Steve has addressed this several times as work-in-progress. We have our finger's crossed while already enjoying the advantages. Regarding the NPM/CSS/Webpack comments above: this example here https://github.com/BlazorExtensions/BlazorMaterial handles it elegantly using "standard" .NET/Visual-Studio features.

I need to port in a standard System.Web.Services.Protocols.Soap library, but it is not compatible, what can I do?

Great article! I have just used Certify to add an SSL certificate for a IIS based website in less than 10 minutes.

Hi Again,

In my last comment I forgot to tell you that I'm using the builtin BinaryFormatter. I just read the comments on your original PropertyBag post, which also was about deserialization. I changed my code to use JSON.Net instead, I now I get another error: Member 'value' was not found.

Any idea?

Hi Rick,

Very nice and thorough post which hopefully helps me with the limitations of dynamics and the builtin ExpandoObject. I have a couple of problems though - and they occur both with your code shown in this post, as well as with the Westwind Nuget package:

When serializing I get an error about PropertyBag not being marked as serializable. When adding the tag to the class, serialization works. But then deserialization fails with an error about PropertyBag not having a constructor to deserialize the object.

Do you have any idea on whats wrong?

For .NET Core 2.1 in order for the TestHelper.GetIConfigurationRoot code to work I had to add some nuget packages. Looks like they split the different configuration options into different nuget packages. Below is the different packages that I had to add.

SetBasePath and AddJsonFile => Microsoft.Extensions.Configuration.Json

AddUserSecrets => Microsoft.Extensions.Configuration.UserSecrets

AddEnvironmentVariables => Microsoft.Extensions.Configuration.EnvironmentVariables

Hi, Thank you for your post very usefull. I found also an easy way to get the configuration file

https://www.jerriepelser.com/blog/using-configuration-files-in-dotnet-core-unit-tests/

@Peter - Basic authentication is a really old protocol and it is very insecure because it passes username and password in the 'auth token'. IOW, it can be easily compromised by anybody who either listens to an un encrypted connection (man in the middle attack), or even just gets onto your physical machine in any way. The password is there in plain text (well base64 encoded anyway).

If you're using IIS and .NET you can use Forms Authentication for programmatic processing, or if you want to use Windows accounts you can use Windows Authentication. Both use authentication tokens that are not directly associated with your account.

"why you'd want to use Basic Authentication on a web service is beyond me" Could you expand on this please. I am a bit new to all this, but I am writing an IIS hosted web service and had got the impression from my reading that basic auth was the norm. So what would you recommend instead?

Thanks for the article by the way

Amen! Many developers were roughly 2 to 5 times more productive in the desktop days. It seems everyone is "okay" with this Yuuuge sacrifice to get the web's easy deployment. Is there any absolute law of the universe that says the trade-off between sane UI development and deployment ease are inherently at odds? Let's see the math! I actually see that nobody has seriously tried, at least in Open Source. We need a "GUI browser" standard that starts with the assumption and goal of desktop-like features, not "web pages".

@mikey - you can specify port 80 as the self-host port which will then work without the port in the browser.

But you'll likely run into problems as something else (IIS? Skype?) will likely already be using port 80.

is it possible to self host netcore without specifying the port (Just like IIS forwarding)

Is there an equivalent method to JavaScriptStringEncode() in the new AspNetCore packages? I need this functionality but want to avoid using old AspNet System.Web dependencies.

Very good overview about what Blazor is and how it works. Some time ago I decided to create a simple project to compare and contrast development with Blazor with existing JavaScript frameworks (React). You can check out the demo and play with it >GitHub.

I am SO glad I'm not the only one that realized this! As a web developer, and former Windows dev I totally get how UI input controls are so lame compared to even what was out the box in VB 6. Ten years ago I sorta hoped that XAML would just replace HTML, even though it has its own issues. That didn't happen... And I don't think I have a more intense love/hate thing than with CSS. It can do 'anything' but at the same time is insane in its complexity. You can't even figure out what happened without F12, and God help you if you are debugging someone else's CSS. Anyway Rick, if you want to invent something new that replaces all this, I go in with you.

Hmm, I wouldn't say that the risk is necessarily low. Moreover if there's anything JavaScript taught us, it's that you probably shouldn't silently coerce types based on their content. 😉

Have you considered an implementation on the string prototype? It won't do it automatically, but it will make it a lot more convenient.

String.prototype.toDate = function() {return new Date(this)}
Date.toDate = function() {return this}

This technique essentially gives you an method you can use on either a date or a date-liked string. If conversion has already happened, nothing more happens. If conversion has not happened, it happens. Eg:

let myVal = '2014-01-01T23:28:56.782Z'   <-- Presumably came from JSON deserializatoin
let myDate = myVal.toDate()

At this point, if you pass myDate to a function, you can call toDate() again just to be sure.

function foobar(myDate) {
    myDate = myDate.toDate()
}

Not an ideal solution, but better (IMO) than silently changing a variable's type based on its contents, which I consider a troubling proposal.

Having said that, I'm half-inclined to just go back to xmlrpc. At least it (de-)serialized dates without intervention.

@Jesse - thanks for the heads up. Updated the post. I guess I must have just not noticed that this has been there. Maybe even longer than VS 2015?

I have that drop-down in VS 2015 (14.0.25431.01 Update 3).

@Michael - thanks for the generous donation. Glad to see the content is useful to 'ya...

Thank you, Rick. I donated $10 for you to buy a cup of coffee! I'd like to know that you received the donation. Great content, as always!

~ Michael

@gby - thanks for the heads up. I've clarified the code to read: WASM is a binary code format that deals with instructions at the stack and memory level. Push things onto the stack, call an operation to perform an arithmetic operation or call a function pointer with the stack set to 'pass' values.

Chris Hass is right - MS need to come out of experimental regardless of the timescale to implement. It's a huge 'Bill's betting the farm on this', but that's what needs to happen. Timescale wise it needs to be this autumn if we're really serious.

@Chris Hass - Same language on client and server is not new to .NET. You've been able to do this for a long time in JavaScript with Node on the server and JS in the browser. Especially now with frameworks having both server and client side parts of said frameworks.

Still, I agree to some degree, because it just seems a lot easier to do component development that works across the entire platform in .NET as it is in JavaScript. A a lot of the problems in JavaScript is the huge fragmentation that ends up pinning 'components' to a specific framework. At least that has been my experience - I often get hung up by the age old problem I need a component to solve problem X - now I have two problems 😃: Adding managing the dependency chain for the Component Y.

Unfortunately I think those same problems are likely going to continue with Blazor because Blazor is using that same HTML based eco-system and if we continue to use HTML/CSS/JavaScript to extend the HTML space even with Blazor we're not really sidestepping all the issues, just deferring it out more to the edges...

The proof will be in the pudding and how rich of an eco-system is possible around pure Blazor components and how rich Microsoft can make the build tool chain. And this is where I think the eventual success or failure of Blazor has to be judged.

Great article. I've ALWAYS hated Javascript and this "vision" is more or less what I have always dreamed of. Can't wait to use the final product.

Awesome article Rick - really good to know we've got a respected voice driving things forwards.

Some interesting stuff from Rockford Lhotka too via Xamarin. I was wondering why Xamarin if we've got ASP.NET or UWP running thro' WebAssembly, but of course there are iOS/Android specific APIs.

Proof of the pudding will be a decently complex, fast app. Hope MS do something like the IBuySpy e-commerce site, it was a decent example in its day. Currently the flights example doesn't cut the mustard, but hey, it's early.

Timescale wise I guess we're looking at VS2019 Spring earliest. Wouldn't it be awesome though? When MS set their sites on a real challenge they do come up with the goods as per .NET, so I hope folks like you will persuade them to go for the big push.

Great article with excellent balance, nobody does it better than Rick!

"For example, it would be quite useful to have business validation logic that can be executed both on the server and client."

This one idea is what really makes blazor stand apart from any js client side framework I have seen. I think this was a very objective article pointing out both sides of why this may or may not make it out of experimental stage. That said, blazor or something else will overthrow javascript in the next few years. The js toolchain itself is a mess, but in addition the constant js flavor of the month framework churn is just as daunting.

MS has more of a shotgun approach just throwing out stuff and seeing what sticks. I encourage MS to enlarge the current blazor team soon, as it seems like a very small right now. It's tough to get people to constantly test out your ideas (for free) but a lot of people are on this one.

Lets not forget there are a lot of programs that are just server side mvc or server side asp web forms that function well enough and don't demand the performance. Nearly all intranet apps with only a dozen or hundred users don't benefit enough to justify the learning curve of implementing a SPA. This technology IMO removes that learning curve and is comfortable to the MS intranet developer.

They need to commit to this effort by year end taking it out of experimental stage or I fear momentum will be lost. I'm not saying release end of year, I'm saying commit by end of year.

I think it's time for Browser2. The browser completely rethought. Don't even call it a browser. Don't make it backward compatible with HTML. At first it will be used internally in corporate environments. It will eventually catch on. Our children/grandchildren will thank us.