I love SourceLink - it’s fast becoming a standard practice to include SourceLink support in all open source NuGet packages in order to make them easier to debug. We’ve included SourceLink support in Akka.NET and some of our other projects for some time now.
However, I’m embarassed to admit that I’ve never been able to remember how to get this to work properly each time I switch machines or projects. So, I decided to document how to do it.
Step 0 - Verify That Your Third Party NuGet Packages Actually Support SourceLink
Before you go through the trouble of configuring Visual Studio to support SourceLink you’ll want to make sure that the third party package you’re trying to debug actually supports it.
The official Microsoft documentation on SourceLink has some guidance for how to do this, but odds are high that popular NuGet packages (i.e. ASP.NET,...
Over the past week there’s been a ton of chatter about the state of the .NET ecosystem and, more specifically, as to whether or not its OSS ecosystem is healthy and sustainable over the long term.
I won’t bother with the details, but the substantive criticisms amount to:
- If you build a popular OSS technology in .NET Microsoft will simply cannibalize it and roll it into a 1st party feature (i.e. Entity Framework cannibalizing NHibernate, built-in DI in ASP.NET Core, etc;)
- .NET users are still overwhelmingly Microsoft-centric - i.e. if Microsoft told its users to store all of their passwords in plain text at least 30% of them would blindly do it because Microsoft said so without considering any second opinions;
- The .NET ecosystem doesn’t built anything “cool” - there’s no innovation here and thus no real way to attract fresh ideas and younger talent to the ecosystem; and ...
This is largely the text of an issue I posted related to the .NET Foundation’s new proposed Maturity Ladder for .NET OSS projects. I am fully supportive of the .NET Foundation’s stated mission and wrote this in the hopes of trying to help it achieve that through a little tough love.
After reading (.NET Foundation Directory) Jon Galloway’s reply here I want to raise a fundamental problem that exists with the .NET Foundation in its current form that makes some portions of the ladder proposal distasteful, in my eyes as both the proprietor of an independent .NET OSS business, a project contributor, and as someone who deeply cares about the success of the .NET OSS ecosystem as a whole (it’s why I started Petabridge.)
Microsoft and the .NET Foundation are effectively joined at the hip. Its day to day operations and run by largely by Microsoft employees...
In my professional life, I’ve actively conditioned myself to tolerate and accept risks when necessary. Risk tolerance is something that can be learned and taught. But risk tolerance is fundamentally a contextual matter - two people with identical means and skills can have totally different reactions to the stressors risk presents.
There are people who will go skydiving but won’t ever, ever leave their stable corporate job that they hate because the alternatives terrify them. There are people like me who won’t jump out of a perfectly good plane, even at gunpoint, but feel totally comfortable entering work situations even with uncertain economic outcomes.
I’m generally confident and assertive, but my biggest regrets in life have come from situations where I failed to be either. In these moments I make a common mistake: when I weigh my choices, I invent additional possible negative outcomes that don’t actually exist.
Chief among the values prized by fellow millennials is comfort. It’s reflected in our more casual dress and our increasing preference for impersonal forms of communication, such as text or Slack. Our desire to form self-reinforcing informational and social bubbles, where we can limit our exposure to different and potentially disagreeable ideas, is fundamentally driven by a desire to avoid discomfort.
Our comfort fetish began with the “self esteem” movement in the early 1990s, when we were elementary aged-children. It culminated into the (rightfully) maligned “participation trophy” culture. And the trend simply continued on under its own momentum from there, leading to the rise of Safetyism and other developmentally self-destructive movements. The pursuit of comfort above all else puts us in a position where we simply sit through and endure the bad hands dealt to us by circumstance.
It was roughly a year ago this week that I fled California in pursuit of greener economic pastures. I came to Texas an economic refugee; despite running a successful business in California for a number of years I watched my profit steadily fall beneath the relentless tide of cost of living inflation, taxes, and so on.
It’s a move I’d been wanting to make for years but timing and circumstance stayed my hand until April 2017. And it was a difficult choice too - I was leaving behind my family in California, who are a short drive away from where I lived in Los Angeles. And I really loved LA itself - it’s a great city where you could do something different every day and not see a tenth of it by the time you die.
I made the choice to leave, happily, because it’s backed by intention: I’m not...
I spend a lot of my professional time training other software developers on how to build next-generation applications. Distributed and concurrent systems; stream processing; stateful web applications; soft real-time applications; and so forth. Cutting edge stuff for the majority of my industry.
One of the huge advantages of inexperience, such as when you first graduate from school, is your default state of being with the world is one of perpetually learning and adopting new skills and techniques. You’re not intimidated by taking on a project with lots of unknowns because… every project feels that way during the beginning of your career. But once you’ve been in your industry for a few years you pick up a few things: tools, tricks of the trade, techniques, pitfalls, preferences, methodologies, and so forth.
Fast forward to your five, ten, or fifteen year mark in your career you’ll run into what is an existential...
There’s been ample grumbling about various changes in the .NET ecosystem of late, but I’m more excited about .NET than ever.
First, the decoupling of .NET from Windows. Mono started this work in earnest 15 years ago, and .NET Core + UWP is the next step. Turning .NET into a universal and lightweight runtime introduces many possibilities that haven’t been feasible for many before. Particularly in areas like HA systems, IOT, embedded computing, and mobile. And maybe even inside the browser with WebAssembly.
This is going to create new jobs, new types of applications that weren’t possible in .NET before, and broaden the .NET OSS ecosystem into new directions and areas.
Second, the newfound focus on CLR performance has been a long time coming. It’s not just Microsoft doing this either; read Matt Warren’s blog if you want an amazing third-party example. The improvements coming from this area...
So, BUILD 2017 has come and gone and lots of new exciting updates have been announced or made available for preview in .NET-land, most notably the preview release of .NET Core 2.0.
However, the issue that grabbed the attention of many of the developers in the .NET OSS space was this small change that snuck its way into ASP.NET Core 2.0 preview , wherein the ASP.NET team dropped support for NETFX (the full .NET framework) without any discussion beforehand. That thread is massive - sitting at well over 500 comments at the time of writing this, but the issue was resolved and clarified during a panel discussion with the ASP.NET leadership at BUILD this week and well as an earlier, official blog post:
This preview version of ASP.NET Core 2.0 ships with support for the .NET Core 2.0 SDK only. Our goal...
This is the second post in a 3-part series on property-and-model based testing in FsCheck in C#.
- Writing Better Tests Than Humans Can Part 1: FsCheck Property Tests in C#
- Writing Better Tests Than Humans Can Part 2: Model-based Tests with FsCheck in C#
Testing Richer & Multi-Feature Scenarios with Model-Based Testing
A property test is meant to be fairly succinct and verify that simple properties hold true for all possible inputs given a set of preconditions. But what if you need to test a more complicated scenario, like one where the state of a given object is influenced by the previous operations that might have occurred?
Our previous example of the
FixedSizedList<T> or really any type of collection is a good example of an object. The state of that object will be determined...