"RunAs /NetOnly" functionality from C# code

Only recently I've learnt about the "/netonly" flag availability for "runas" command. I was really happy to find it, but the issue came later.
It turns out that the runas.exe command can't be automated, as it accepts passwords only through a prompt. So there is no way to pass in credentials without the prompt.

That made me seek for a custom solution for the problem. What it turned out is that the .Net Process API doesn't expose any functionality to control the process creation the way, which "/netonly" flag would results in.

Long story short, I came up with the following solution:
The CreateProcessWithLogonW Win32 API, which is being called internally by runas.exe, has a number of parameters indicating how exactly the process should be created. One of these parameters is "dwLogonFlags". The set of values it can take has one called "LOGON_NETCREDENTIALS_ONLY". From MSDN documentation for that value: "Log on, but use the specified credentials on the network only. The new process uses the same token as the caller, but the system creates a new logon session within LSA, and the process uses the specified credentials as the default credentials.". This is exactly what I need. After few hours of unsuccessful search for a C# code sample, which would create a process with this flag, I ended up creating my own.
The sample code is available for download at: http://1drv.ms/1LeqKnD

Hope you find this useful !

The Compatibility Pattern: Designing adaptive classes

Any non-deprecated system, soon or late, faces challenges. Some of these challenges are quite common. The two following items represent just a fraction of those:

• existing file storage doesn't satisfy current/coming space requirements
• the data model need to be modified/extended to comply with new requirements

Today I’m going to describe a design pattern, which can be applied in a variety of situations (including the two above) and eliminate the pain of code re-write.

So, for the sake of simplicity let’s concentrate on a single scenario. Let’s assume we have an existing system – which is operational. Let’s also assume that “EntityA” is an entity in the data model of the system, and the records of that entity are processed by some business logic: “LogicA”.  So far the system used to operate just fine. Now – new requirements come in – which introduce changes to “EntityA” and the “LogicA” as well. Specifically, new “EntityA” records should be treated differently than the “old/current” records. For the sake of simplicity, let’s limit the changes in “EntityA” by just one new field “Field2”. So here what “EntityA” will look like:

where “Field1” is an existing field on the entity. Note, that I intentionally don’t mention the types here as its irrelevant in this context.

Also, let’s assume that “LogicA” is already encapsulated in a class with the same name, as follows:

Now, back to the new requirements, which affect “LogicA”. The simplest way to handle the change would be to modify the “LogicA.ProcessData” method. However that won’t be maintainable. Think about any future changes – affecting the same logic. After several such changes it’ll be really a mess and it won’t be easy to figure out how to change something  to impact only specific version of entities. So the simplest and design-wise proper solution would be to introduce new LogicA_New handler for the new entities and put the decision logic of instantiating the proper logic in some factory class. The following diagram depicts that case:

Note, that the abstraction of the handling logic into separate classes is an implementation of the Strategy design pattern.

This model allows future expansion of the system by just defining a new strategy/logic and updating the factory method, to return the proper handler type. Handling logic deprecation is quite straight forward as well, and can be handled in the reverse order: the factory method is updated to remove the obsolete case and the appropriate logic handler is removed.

Hope this will save you some time in the future.

The interview process

Looking back - there were many times I’ve went through an interview process for different software development positions in different companies. To be more precise – there were around 20 interviews I’ve went through. Frankly saying, it doesn’t matter what kind of company you’re interviewing for – 60% of the technical questions will be very similar (of course, there are rare exceptions to this rule). And if you’ve gone through at least 5 interview processes, you probably know what to look for - how to prepare for those questions.

Why ? Because most of those questions you’ll be asked will be just formality and well known mathematical problems. It’s just a matter of filling in a checkbox whether you’ve answered a question or not – and the chances you’d be ever dealing with that kind of problem during your day to day work – are almost 0! To answer these kind of questions you’d need to just have walked over any similar problem in the past. Most of those share very similar solutions.

These 60% are the bad part of the interview process and I call – THE INTERVIEW TAX. Because you have to learn those anyway even if you won’t be dealing with anything close to those questions.

Now, let’s talk about the other 40%. Those divide into three categories:

• Thinking questions
• Practice questions
• Design questions

1. Thinking questions

These may easily be unsolvable mathematical problems as well. And the interviewer is asking you the question and also ask to think loudly. This is important as what he/she wants to observe – is how you think. Or – do you think at all. I know it’s funny, but I’ve seen people just having no ideas on how to solve a problem.

On the other hand, the problem can be really simple as well – very trivial – but the discussion around it will be like building a knowledge graph: you say something, you get another question on what you said, you answer again, and again get a new question – which slowly takes you away from the original topic. These discussions can take hours (luckily the interviewer will have a schedule).

2. Practice questions

The questions here are simple coding questions in your preferred programming language (unless the company has strict requirements about the coding language). In most of the cases – even a pseudo-code will be fine. These questions are aimed to verify your coding skills – like properly handling validation, corner cases. In the end you most probably will be given also a task to write unit-tests for your code. The interviewer may have noticed a mistake in the code, and sometimes want you to catch it – so be careful to do so. If you’ll write a code and the tests you’ll write won’t handle it – that’ll be reflected negatively for you.

3. Design questions

This is my preferred topic. Unfortunately these are quite rare questions during the interview process you get asked. I believe those are the most valuable ones as those will be giving answers on how well you’ll be doing your work – if you’ll be hired.

Anyway – here you may be given some real-world problems – and you’d have to solve it – by describing a system from a high level. The system can be very small or very big – depending on the responsibilities you’re being considered for. But even on the smallest systems (a simple example is an elevator or an alarm clock) some important skills can be seen.

I hope this writing will be a good overview for one who is looking forward for an interview and also for those who host interviews – to improve their existing processes, if they fall in the 60% category.

C# 6.0: The great changes

It's now more than 10 years I'm writing code in C# and I enjoy every part of it. It gets better with every version, and there is no exception in the coming version: C# 6.0.
Everybody who had ever dealt with MVVM pattern, will be well familiar with the INotifyPropertyChange interface. The tedious part of the implementation were the constants (I used to have constants always) you had to define per each publicly exposed property - to store the name of the property.
I recently had a post about how to retrieve the property names dynamically using reflection (here), but still it's not everyone would consider a good option to go with. C# 6.0 mitigates this pain with a new keyword called "nameof".
To get the name of a property you'd simply write: nameof(PropName), and this would return "PropName". Really cool !

And now the other thing I am happy about. Remember the String.Format("Name: {0}", record.Name)  way of doing things ? There were many issues I've seen where updating the format one forgets to add additional parameter, or adds one, but forgets to add the '{X}' placeholder for it - which would cause a runtime exception. C# 6.0 changes the mechanism completely - as now instead of the placeholders you'll just refer to the values within the format string. That's much more readable and safe:
String.Format("Name: \{record.Name}")

And there is much more...