How can I create a custom *write-only* dependency-property?

I need to know what the procedure is for making a write-only dependency-property. I can see that the DependencyProperty class does not have a special "Register" method for write-only properties, but I have no idea whether the RegisterAttached method may apply to what I am trying to do.

This property needs to be a dependency-property, rather than a simple CLR property. Internally, my class requires a PropertyChangedCallback on this property in order to remain stable.

I know that write-only dependency-properties can be created, because it is stated quite clearly in:
Pro C# 2008 and the .NET 3.5 Platform, Page 1061.
However, this is the only place where I can even find "dependency property" and "write only" on the same page. And this author apparently did not think it was necessary to actually show the reader the procedure for anything other than a basic read-write dependency-property. Of course, this book could be a load of BS - but this book looks pretty standard, so I think it's a pretty safe bet that the author is correct. I assume the lack of information on the internet stems from the fact that nobody generally needs to make a property like this.

I know it sounds very questionable to want to make your own write-only dependency-property. I assure you it makes sense where I want it. My class has a property whose value is only useful to the object setting it. If another object were to request the value of this property later, it wouldn't be able to make any rational sense out of the value without knowing the original context of the setter.

This property is not intended to be used for informational purposes. Letting outside objects attempt to use the property value this way is problematic, dangerous, and a security risk. So I believe the best design is to prohibit read operations on this property. Anyone using my class will find that they are forced to use the class the way it was intended, which will work out much better and cleaner in the end.

You can't, this appears to be by design. While I can understand your approach to the mentioned book and am in no way questioning its quality, I'd still presume this to be some sort of copy&paste or similar issue. Here is my reasoning:

WPF property system code

• As you mentioned already the public API of the DependencyProperty Class only features RegisterReadOnly() and RegisterAttachedReadOnly().
• Speluncing in the class internals via Reflector only reveals dedicated code for handling these Read-Only Dependency Properties, there is nothing in sight regarding write-only functionality.
• Another option might have been metadata, but neither Dependency Property Metadata nor in particular Framework Property Metadata by means of the FrameworkPropertyMetadataOptions Enumeration is providing anything along the lines of write-only.

WPF property system design

• More important, 'The current WPF implementation of its XAML processor is inherently dependency property aware. The WPF XAML processor uses property system methods for dependency properties when loading binary XAML and processing attributes that are dependency properties. This effectively bypasses the property wrappers.', see XAML Loading and Dependency Properties.
• Most important, 'Dependency properties should generally be considered to be public properties. The nature of the Windows Presentation Foundation (WPF) property system prevents the ability to make security guarantees about a dependency property value.', see Dependency Property Security.

Especially the latter two points are outlining the design constraint, that dependency property values are always accessible via GetValue()/SetValue(), no matter whether their CLR wrappers are access restricted or available at all, with the only exception being the specifically accounted for Read-Only Dependency Properties.

Consequently, as Jeffs answer implies already, just removing the getter for example does not really prevent anyone accessing the property via GetValue(), though this may at least 'reduce the immediately exposed namespace of a custom class'. The usefulness of any such semantic workaround of making the property value somewhat less visible/accessible and the retrieved value inherently useless for clients as suggested by Jeff depends on your particular scenario of course.