Sure, I expect I will expand my use of unit testing in the future, do a good job of it, and reap the benefits.

Yeah, kinda. I feel it's less tedious/rigorous/exhaustive than TDD as I've seen it explained. I've seen TDD promoted as an iterative design aid: you don't know what you're doing exactly so you write a test which uses an imaginary API, then try to get the test working. Then you reflect a little more and adjust the test and write some more primary code. There are some benefits of this such as you've got only a very short departure from code that runs at all times. However the test *driven* nature of it doesn't sit well with me. I like to do as much up-front-design as I can: in my head, on paper, as formal requirements, whatever. In the Unit Testing I admire, it's more of a "there, I deliberately broke something, and when I'm done it won't be broken anymore". You're not so much testing for correctness or using it as a design process, as you're throwing spanners in your own gears and making your code cope. It now 'covers more ground' than it did previously

OK, I was a little vague about that. I've seen people write tests that exercise getters/setters, behaviour from missing arguments, etc. In Java at least, a few good annotations takes care of all that rigmarole and you don't need to write tests for that stuff. But let's talk about tests which 'confirm expected behaviour'. I feel like this kind of test is a waste of time until we've encountered a non-expected behaviour that we want to squash and know that it stays squashed. Because 'the expected behaviour' is already a path we have trodden while developing/debugging, and obviously we wouldn't think we're done until it's behaving as expected already. But our oversights are the things we need to come back for and scaffold with some tests, because we're prone to overlooking some aspects of the state-space and need that support. It's about benefit vs bother in the end. You have to cherry-pick your testing opportunities and get on with making the code. IMHO.

The best use of unit-testing I've seen (ie. admired, admittedly from a distance thus far) is to create a test that breaks in a meaningful way (when fixing a bug, it tickles the bug and fails ... or when adding a feature, it tries to perform the actions that are not yet implemented). Then, 'fixing the bug' or 'implementing the feature' is 'done' when your test passes. The test lingers on ... because it continues to pass, you know that your latest changes didn't take other parts of your code backward. A great example of this discipline in action is the main dev of jOOQ (Github link)[^] ... he pretty much doesn't start a bit of new code without an issue and a failing test. Unit testing should absolutely not be used for things like double-checking that code does what the complier pretty much says it will. Less is more.

That's almost certainly what is being taught. It comes from the (very helpful) book 'Design Patterns' by Erich, Gamma, et. al. (aka. 'the Gang of Four' ... abbreviated everywhere to 'GoF'). It is useful in particular situations, and it has trade-offs. Professors should teach it, but I doubt they are advocating that it should be always done that way ... that's more likely students not grasping the nuance of when to apply the pattern.

The book sounds pretty dubious, but recently I've been exposed to architects and builders in the context of a real building. Architects deal with such matters as how space is used, or how to make a space so that it can support various kinds of uses. They're aware of dimensions, of materials, of light, of acoustics, of cost, of functions, of aesthetic, of legal boundaries, of stakeholders, of how people interact with spaces, and all that sort of thing. Ultimately they are great at devising trade-offs and their knowledge is extensive. Builders however, when told to build a wall right there, are thinking about quantities of materials, where to get them from, of how things will joined, of angles and frames and cladding and hinges, the order of operations, whether the stuff will fit through the door on the way in, and who's going to hold that while another person fastens it. It's actually quite amazing watching how they are so complementary yet also quite ignorant of the domain of the other specialist. Yet somehow the building gets done. That co-operation is partly facilitated by a drawing, and partly through them each each talking to the same stakeholders. But wait, there is another specialist too! The draftsman makes a drawing, and he/she is actually very selective in what each drawing is 'about' and 'for' and therefore what it includes or excludes. A set of drawings is typically needed to establish context, indicate dimensions/boundaries/locations, label space usage. These drawings will each focus on different features/aspects of the building. One of the most marvellous books I ever read that I felt got close to this 'plan' is now out of print (last time I looked): "Problem Frames" by Michael Jackson (no, not that Michael Jackson). It conceives of domains and machines connected by phenomena, and explicitly describes the software task as "configured this machine to ...". So when writing a browser app, it would very specifically call out the user browser (or the mobile device, if warranted) as a machine in which the programmer needed to produce some effect, in order to satisfy some requirement. Anyhow, if we're going look to architecture/building as a model for getting complex projects done, we need something like this is needed to fulfil the role of the 'plan', and the Problem Frames book is a good start.

The book sounds pretty dubious, but recently I've been exposed to architects and builders in the context of a real building. Architects deal with such matters as how space is used, or how to make a space so that it can support various kinds of uses. They're aware of dimensions, of materials, of light, of acoustics, of cost, of functions, of aesthetic, of legal boundaries, of stakeholders, of how people interact with spaces, and all that sort of thing. Ultimately they are great at devising trade-offs and their knowledge is extensive. Builders however, when told to build a wall right there, are thinking about quantities of materials, where to get them from, of how things will joined, of angles and frames and cladding and hinges, the order of operations, whether the stuff will fit through the door on the way in, and who's going to hold that while another person fastens it. It's actually quite amazing watching how they are so complementary yet also quite ignorant of the domain of the other specialist. Yet somehow the building gets done. That co-operation is partly facilitated by a drawing, and partly through them each each talking to the same stakeholders. But wait, there is another specialist too! The draftsman makes a drawing, and he/she is actually very selective in what each drawing is 'about' and 'for' and therefore what it includes or excludes. A set of drawings is typically needed to establish context, indicate dimensions/boundaries/locations, label space usage. These drawings will each focus on different features/aspects of the building. One of the most marvellous books I ever read that I felt got close to this 'plan' is now out of print (last time I looked): "Problem Frames" by Michael Jackson (no, not that Michael Jackson). It conceives of domains and machines connected by phenomena, and explicitly describes the software task as "configured this machine to ...". So when writing a browser app, it would very specifically call out the user browser (or the mobile device, if warranted) as a machine in which the programmer needed to produce some effect, in order to satisfy some requirement. Anyhow, if we're going look to architecture/building as a model for getting complex projects done, we need something like this is needed to fulfil the role of the 'plan', and the Problem Frames book is a good start.

Big relief: https is NOT required for OAuth 2.0 redirect_uri which use 'localhost' as the hostname (at least with Xeros Authentication Server anyway ... it is possibly a requirement of the spec). A good thing too, or else presenting a clean certificate for 'localhost' to the user's browser (kind of super-important when getting the user to trust your app to access their resources) would require presentation a self-signed cert that's trusted by the host. Which would require generating and adding adding it to the trust store at some point in time prior to the moment it is used. Which would require privilege-elevation prior to the moment it is used. Which we are trying to avoid with ClickOnce.

Yeah, this could work, but ... https. Getting closer. CoeProject: Simple HTTP Server in C#[^] GitHub Gist: Simple HTTP server in .NET Core using TcpListener[^]

For the purposes of an OAuth 2.0 Client, I need to parse a HTTP GET with no body, and return either this pre-canned HTML (success) or that pre-canned HTML (fail), maybe serve up a bit of CSS and an image or two. Every other request I can respond 404. I have elsewhere explained that I can't use anything based on System.Net.HttpListener for this purpose, because that puts me in the situation of needing to elevate privileges on the host at least *sometime previously* ... but this app is ClickOnce so-as-to-avoid-the-need-for-admin-rights ... especially the need for admin rights in order to setup the app to receive an OAuth 2.0 authentication code! System.Net.TcpListener dodges the 'urlacl' infrastructure though. Sure, it puts more responsibility on me to 'be a webserver', but as explained, the 'functional surface area' of this web-server is quite small. So whether I write-my-own or import some dependencies, I feel like this *should* result in either a little bit of code, or a few minimal dependencies. Is this expectation reasonable, do you think, or are there gremlins in the forest? Are there any minimal 'sits on top of TcpListener' HTTP libraries/servers you are aware of?

I would like to submit my reasoning for validation/sympathty. If your head is not already full of OAuth 2.0 the language here might not make sense. Some context is required: * The Resource Server is Xero * The Authorization Server is Xero * The Authorization Server permits registration of Clients which use either the 'Authentication Code Flow' or the 'Authentication Code + PKCE Flow' * The Authorization Server correctly requires Client registrations to supply a 'redirect_uri' * The Authorization Server incorrectly requires Client registrations to supply a 'redirect_uri' only with an https:// prefix :sigh: * The Client is my .NET desktop ClickOnce app * The User Agent (browser) runs on the same machine as the Client, in the same desktop session * the User making the OAuth 2.0 delegation does not otherwise need admin rights to the machine ... and the Dev (not really the subject of an OAuth spec, thank heaven!) just wants to get on and write his business logic. :(( Right, so back to work: :java: To get an access token, we first of all need an authorization code. We get that from the Authorization Server through the 'front channel' ... the User's User Agent (ie. a browser) is given an HTTP redirect to the 'redirect_uri' with the information we need in an HTTP request. And here we run into 'hassle'. IF our Client were an Android, iOS or UWP(?) app, we could have registered for a 'Claimed Https Scheme URI Redirection' ... when the User Agent (browser) visits https://example.com/, it will activate the app and send the URL to us! (so long as we can convince the respective app store WE own example.com ... it's all in the app manifest). But ... that's not us. We're a 'legacy' app on Windows. Well, we could use a 'Custom URI Scheme' and register 'com.example.myapp:/foo' with Windows, which would (after a browser prompt) activate our app and hand the URI over to it (maybe ... it isn't clear if we can do this for ClickOnce apps that are 'installed' in each user's roaming profile). We get the same effect as with the Claimed HTTPS URL approach. But ... that's not us. Xero won't let us use a Custom URI as the 'redirect_uri' anyway :doh: (The article Redirect URLs for Native Apps on Okta (a competing Authorization Server) lays these things out quite neatly. Ldapwiki: Claimed Https Scheme URI R

I'll go ahead and try these things right away. I solved my app.manifest issues by ticking the 'NET Desktop Development' profile in the VS 2019 installer! :doh:

Richard Deeming wrote:

I'm not sure whether you'll be able to use IPC from the unelevated app to the elevated app.

Thanks Richard. For IPC, I hope I can use anonymous named pipes between the processes, per Microsoft's own How to Use Anonymous Pipes for Local Interprocess Communication. I imagine the privileged-child will be able to connect to the pipe created by the unprivileged-parent without issue if it has the token. To pass the result of (new AnonymousPipeServerStream(/*etc*/)).GetClientHandleAsString() to the privileged-child, I will pass it as a command-line argument. I suppose a malicious application could create its own named-pipe, invoke MY privileged-child app to fool the user into approving the UAC prompt (abusing my good name) and then control the privileged-child process from their malicious app. Fortunately I only really need the pipe for signalling the privileged-child to stop ... not to direct the action of the privileged-child. Since I'll be working with ProcessStartInfo anyhow, adding a 'runas' verb is 'within easy reach'. It then becomes a question of whether anything is gained by going declarative. Yes, if I needed the 'verb' for a different purpose, I guess. Or if I wanted the privileged-child code to be useful to an audience wider than my app. No, if I am happy for my privileged-child to fail unless properly invoked by MY code (heck, I could even take steps to make it a lot harder for said malicious actor!), or if I don't wish to draw the attention of malicious parties by marking it 'hey, I run as admin!'.

Hello folks, my first post after years of lurking. The burden of the out-of-date articles on the Internet around .NET technologies is getting really heavy, and I can't quite locate reliable info, and I'm blocked on this. I have asked the question on Stack Overflow, but the quality of the related answers is not encouraging me I'll get a bite. I guess all the real veterans hang out here! I basically would like to force the UAC prompt to do some stuff as admin. I understand I will need a new process and must arrange IPC between the unprivileged-parent and the privileged-child (sounds familiar :-) ). But I don't know if using

System.Diagnostics.ProcessStartInfo.verb = "runas"

is the go, or if there is a Better Way Today. There are articles here and there about using the app.manifest which I can't seem to apply in VS 2019 - they feel defunct. (.NET Framework itself is starting to feel defunct, actually). TIA

I found The Algorithm Design manual to be a really useful survey of all sorts of algorithms and 'war stories' about how they apply to real-life situations. The intent is to equip you, the programmer-in-the-field, to think about your high-n data problems in terms of complexity and adapt and apply algorithms to them. (As opposed to, say, solving abstract puzzles by inventing and implementing algorithms). The Algorithm Design Manual[^]. Be sure to follow the links through to the 'Algorithm Repository' and even what seems to be the complete videos and slides of Prof Skiena's introductory algorithms class if you're interested in that rabbit hole. But the lovely hardback book will never be out of reach for ideas and inspiration.

That's a good analysis, (although I do think that some of the emerging touch-based UI idioms can teach the mouse-based UI state-of-the-art a thing or two). In my latest system purchase, 'can this hardware run an OS other than Windows if I need to?' was a leading criteria. And that's me who's been with Microsoft since DOS 3.1 through Windows 3.0, Win NT 4.0, Win2K, Win 7. I had a happy flirtation with Linux a few years either side of The Matrix (1999!) but I value binary-compatibilty on a week-to-week basis so very much when trying to do real work, that I put up with Windows for its relatively low admin-effort. (Yes, the Linux distros have now largely sorted this). But just knowing that somewhere along the line, Microsoft decided to pinch a few GB of my bandwidth and storage (precious, on my Win 7 Pro laptop) to prime its Win 10 installation files without my desire, consent, or invitation, really speaks loudly to me. The nag adverts for the Win 10 upgrades are insulting in both their frequency and their content. So the latest machine would have been 'Linux host OS', 'Windows guest OS', except I got scared off because of a photo-editing workflow and I wasn't sure how the monitor calibration (and graphics performance) would work out running the Adobe apps in a VM. (I briefly considered *nix-underneath MacOS/X, but that felt like it would be jumping into the fire from the frying pan *and* getting fleeced along the way). I'll have my calibration questions sorted out soon, so that I'm able to make the jump when they get too much for me. Because Win 10 in a sense 'requires' touch, and me purchasing a desktop, I'll be getting a Wacom tablet as well. Fortunately, this makes sense for the photo-editing workflow, and it's probably work out OK. However, one does feel forced into it.