build, security comments edit

ProGet is a very cool, very flexible package and symbol server. They offer a free edition but when you get into the paid licenses you can secure your feeds using LDAP or Active Directory credentials.

NOTE: This is written against ProGet 4.7.6. Inedo is pretty good about getting new and cool features out quickly, so if you don’t see all the stuff I’m talking about here it may have been rolled up into “more official” UI.

Given that disclaimer…

ProGet supports three user directories:

  1. Built-in - the local user store, no Active Directory or LDAP.
  2. LDAP or Single Domain Active Directory - uses a single LDAP directory for users.
  3. Active Directory with Multiple Domains - enables the local Active Directory as well as an additional domain.

General Troubleshooting

There’s a hidden integrated auth debugging page at http://yourprogetserver/debug/integrated-auth and it dumps out a bunch of data about which user directory you’re using, which user account you’re using to authenticate currently, and so on.

I’m not putting a screen shot here because the view would be nearly useless given the amount of info I’d have to redact. Just try it, you’ll see.

Built-in Directory

There’s not much to say about the built-in directory. It’s very simple. Members, groups, done. However, you may, at some point want to test searching for specific users or groups if folks are reporting trouble.

There is a hidden test page for the built-in directory here: http://yourprogetserver/administration/security/configure-directory?directoryId=1

That page allows you to do a test search. There’s really nothing to configure otherwise, so it’s just diagnostics.

Built-in directory test page

LDAP or Single Domain Active Directory

Connecting to the local Active Directory is pretty straightforward. There’s good doc on how to do that.

However, there are additional properties you can configure, like which LDAP OU you want users to be in, and there’s no UI… or so it would seem.

There is a hidden configuration and test page for LDAP or Single Domain Active Directory here: http://yourprogetserver/administration/security/configure-directory?directoryId=2

LDAP/single AD test page

This is super useful if you need to authenticate as a service account for AD queries or otherwise modify the LDAP query.

I didn’t find a way to change the LDAP server here. I may be misunderstanding, but the description on this option makes it sound like that’s possible: “ProGet will use the user and group information of a single domain or a generic LDAP directory.” In practice this option will only use the Active Directory of the account running the ProGet web app. If the web app is running as a local machine service account (e.g., SYSTEM or NETWORK SERVICE) that means the Active Directory to which the local machine belongs.

In order to use a different domain than the service account or machine you need to switch to the “Active Directory with Multiple Domains” option.

Active Directory with Multiple Domains

This option lets you authenticate users against a different or second directory. In this case, “Multiple Domains” means “the default domain and an additional one.”

There is a hidden configuration and test page for Active Directory with Multiple Domains here: http://yourprogetserver/administration/security/configure-directory?directoryId=3

AD/multiple domains test page

I think the “AD with Multiple Domains” option also uses the settings from the “LDAP or Single Domain Active Directory” option, but I can’t promise that. It seems like the configuration page should have the same sorts of values on it but it doesn’t.

vs, uwp, wpf comments edit

In working on a recent project I started getting a bunch of big red X marks in the XAML designer due to various issues in design time. To fix it, I had to debug into the XAML designer itself.

There are several articles out there that say “just attach to XDesProc.exe with the debugger” but this alone didn’t work for me because the errors I was encountering were happening in just such a spot that I couldn’t attach to the designer process before it had already occurred. (We’ll get into why later on.)

Here’s how to debug the XAML designer:

  1. Close all instances of Visual Studio.
  2. Open a command prompt window.
  3. Enter the command setx XPROCESS_PROMPT 1 and hit enter.
  4. Close the command prompt.
  5. Open the problem project in Visual Studio and get to the designer to trigger the problem.
  6. When the designer is about to start, you’ll get a little dialog box telling you exactly which process to debug.
    Attach debugger now!
  7. Open a second instance of Visual Studio and attach to that process. Make sure in the “Attach to Process” dialog you select “Managed (v4.6, v4.5, v4.0)” - you may have to manually change the value here.
    Attach to managed code
  8. If you’re interested in setting a breakpoint on your project code, open your project in that second copy of Visual Studio (the one attached to XDesProc.exe) and set your breakpoints.
  9. Click the “OK” button in the “Attach debugger now!” dialog to allow the first instance of VS to continue the design-time rendering.

When you’re finished debugging you need to turn the prompt off or it’ll keep happening when you start the designer.

  1. Close all instances of Visual Studio.
  2. Open a command prompt window.
  3. Enter the command setx XPROCESS_PROMPT "" (yes, empty double-quotes) and hit enter.
  4. Close the command prompt.

Gotcha: This doesn’t help with assembly binding problems.

The problem I was having was an assembly binding problem. The red X in the designer pointed to an error where an assembly couldn’t be found at design time. It was there fine at runtime, but for some reason the designer couldn’t find it.

It turns out the designer has a “shadow cache” where it keeps a copy of your app for execution during design time. It’s in a location that looks something like this:

C:\Users\yourusername\AppData\Local\Microsoft\VisualStudio\15.0_317bf9c1\Designer\ShadowCache

Each app gets a uniquely-named directory under there. What you’ll find is:

  • The designer creates a separate folder in the unique app directory for each assembly it shadow-copies.
  • Not everything in your app’s bin folder actually makes it to the shadow copy.

That latter point - that not everything makes it to the shadow copy - was causing my problem.

I never did figure out the logic behind what does get to the shadow copy vs. what doesn’t get there. Adding a direct reference to the assembly or NuGet package doesn’t necessarily guarantee it’ll make it.

When you run into this, you get managed C++ errors trying to marshal FileNotFoundException info back to .NET but without any requisite inner exception or stack trace details. It’s basically impossible to figure it out unless you want to start trolling through memory dumps and WinDBG. That would tell you what’s missing but still wouldn’t reveal the logic as to why it’s missing.

I worked around the problem with a two-pronged approach:

  • Make judicious use of design-time checking via if (DesignMode.DesignModeEnabled) checks in appropriate places to behave differently in design.
  • Use knowledge of how the JIT compiler works to separate code that requires the missing assemblies from code that needs to run at design time.

Let me expand a bit on that latter one, since it’s key.

When the XAML designer executes code, it only compiles the code it requires to run. If it touches a type in the system, it compiles it (from the MSIL code in the assembly) so it can be used.

Say you have a control MyControl. MyControl has a view model MyViewModel which then uses an EF DbContext to get some data. If all of that is in code in MyControl then the designer needs to compile MyControl, MyViewModel, and the DbContext. If the designer can’t find all the required EF assemblies, the DbContext compilation will fail, which means MyViewModel will fail, which will bring the whole design time thing crashing down and yield a red X.

To get around that, you can create an interface IViewModel with the properties on MyViewModel. Add IViewModel to MyViewModel and create a second view model just for design time - DesignViewModel - that also implements IViewModel with some simple properties. Now in the constructor of your control, you set your control’s view model to the DesignViewModel when DesignMode.DesignModeEnabled is true. MyViewModel can be passed in as a constructor parameter from elsewhere or set as the data context later in other code.

Point being, you’ve now separated your control code from the view model code by using an interface - and the designer won’t need to JIT compile the full “real” view model, so it won’t look for assemblies that aren’t there and you’ll get a good design time experience.

Yeah, it’s sorta complicated. If I could figure out the logic of what causes the designer to bring an assembly into the shadow copy I’d just, uh, “flag” the missing assemblies (or whatever) and bypass this whole complex thing.

autofac, net comments edit

Alex and I have been working on deprecating the ability to update an Autofac container after it’s already been built. There are lots of reasons for this, and if you’re curious about that or have feedback on it, we have a discussion issue set up. You can also see ways to work around the need to update the container in that issue, so check it out.

However, one of the main reasons we’ve heard about why people want to update the container is to handle conditional registrations. For example, “I only want ComponentB registered in the container if ComponentA is not registered.”

To that end, in version 4.4.0 we’ve added OnlyIf() and IfNotRegistered() extensions to support conditional registration.

OnlyIf() lets you provide a lambda that acts on an IComponentRegistry. You can check if something is or isn’t registered and have some other registration execute only if the predicate returns true.

IfNotRegistered() is a convenience method built on OnlyIf() that allows you to execute a registration if some other service is not registered.

The documentation has been updated to explain how it works including examples but here’s a taste:

var builder = new ContainerBuilder();

// Only ServiceA will be registered.
// Note the IfNotRegistered takes the SERVICE TYPE to
// check for (the As<T>), NOT the COMPONENT TYPE
// (the RegisterType<T>).
builder.RegisterType<ServiceA>()
       .As<IService>();
builder.RegisterType<ServiceB>()
       .As<IService>()
       .IfNotRegistered(typeof(IService));

// HandlerA WILL be registered - it's running
// BEFORE HandlerB has a chance to be registered
// so the IfNotRegistered check won't find it.
//
// HandlerC will NOT be registered because it
// runs AFTER HandlerB. Note it can check for
// the type "HandlerB" because HandlerB registered
// AsSelf() not just As<IHandler>(). Again,
// IfNotRegistered can only check for "As"
// types.
builder.RegisterType<HandlerA>()
       .AsSelf()
       .As<IHandler>()
       .IfNotRegistered(typeof(HandlerB));
builder.RegisterType<HandlerB>()
       .AsSelf()
       .As<IHandler>();
builder.RegisterType<HandlerC>()
       .AsSelf()
       .As<IHandler>()
       .IfNotRegistered(typeof(HandlerB));

// Manager will be registered because both an IService
// and HandlerB are registered. The OnlyIf predicate
// can allow a lot more flexibility.
builder.RegisterType<Manager>()
       .As<IManager>()
       .OnlyIf(reg =>
         reg.IsRegistered(new TypedService(typeof(IService))) &&
         reg.IsRegistered(new TypedService(typeof(HandlerB))));

// This is when the conditionals actually run. Again,
// they run in the order the registrations were added
// to the ContainerBuilder.
var container = builder.Build();

If that’s something you’re into, head over to NuGet, grab v4.4.0 of Autofac, and try it out. Find something not working? Let us know!

ndepend, net comments edit

It’s a new year, and with that comes a new version of NDepend - 2017.1. I’ve looked at NDepend before and am a big fan. This time they’ve added a feature that I’m particularly excited about: Technical Debt Estimation

One of the challenges I’ve seen when trying to communicate to non-technical folks about things I find in NDepend is cost. “How much is it going to cost to fix issue X?” Estimation is a tough thing. Now NDepend can help you with that.

First, in your project you need to configure your Issue and Debt settings. This is where you set things like…

  • How many work hours are in a day / work days in a year?
  • What’s the average cost of a person-hour (and in which currency)?
  • What are the various thresholds that define issue severity levels?

There are quite a lot of configuration options. Luckily, NDepend provides a lot of good doc on what the settings mean so you can configure them based on your project/company. And if you have a lot of projects that use the same settings, you can share the settings with a central .ndsettings file.

Issue and Debt settings (click to enlarge)

For my example, I’m just using the default settings.

Once you have that set up and you run analysis, your dashboard will show you your debt “rating” based on the SQALE method and estimate the amount of effort to improve the code to the next rating.

Debt displayed on the dashboard

The little “Explore Debt” button there will open up a query window that shows, for example, how much it would cost to fix each of the various queries you’ve applied to the code.

Debt associated with queries

In this case, you can see that this project has some pretty extensive debt related to the UI talking directly to the data access layer - 47 days’ worth if I wanted to fix it all! However, I might be able to fix up some static field naming conventions in a couple of days and save myself a day’s worth of interest accumulating each year - head it off before it gets too big.

I can also look at a prioritized list of types to fix - places I might get the biggest bang for my buck.

Prioritized type list

How much is it going to cost in terms of money, not just time?

Simple enough, just update your Issue and Debt settings to show both time and money…

Change value format

…and the report automatically updates to reflect that:

Prioritized type list with time and money displayed

Obviously it may take some tweaking of the settings to reflect the situation in your environment, but this is a huge help when it comes to communicating cost/benefit when looking to update code that is working but is worth cleaning up.

And, of course, you shouldn’t let anyone instantly just take it as gospel. It’s a tool. It will help you get started and make it easier to communicate, but you really shouldn’t substitute a generated estimate for something provided by the people actually doing the work.

Go grab yourself a copy of NDepend 2017 and get estimating!

Full disclosure: I got a free personal license from Patrick at NDepend. However, we have also purchased several licenses at work and make use of it to great benefit.

blog, downloads comments edit

Over the years I’ve pushed out a lot of little downloads, source, and code snippets on my blog. Yesterday I finally got all of that moved out of the various little dump sites on disks and in private repos and into GitHub.

I’ll continue updating links and adding things when I find them, but you should be able to see most everything there:

  • Repositories (contain more fully-fledged projects and things that can be built)
  • Gists (contain one-off files and snippets)

It was kind of a blast from the past looking at some of that stuff. I can see how I’ve changed styles and improved. Who doesn’t look at stuff they wrote 10 years ago and shake their head?

I could also see where I used certain tools or tech back then and don’t anymore. Like… remember when T4 didn’t exist and CodeSmith was the way to generate things? Anyone remember the Prototype JS library? Building with NAnt?

I can’t promise all of it will compile as-is. For example, I see a lot of VS 2003 and VS 2005 solutions in there. Will that straight-up convert to VS 2015+? Your guess is as good as mine.

Anyway, it felt good to get things centralized, even if it’s not all stellar code.