<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Preventing third-party derivation, part two</title><link>http://blogs.msdn.com/ericlippert/archive/2008/10/06/preventing-third-party-derivation-part-two.aspx</link><description>If you find a class in a library that has all private/internal constructors, it is pretty clear that the author of the class is sending you the deliberate message that this class is not to be extended by you. In our previous example, it was not so clear.</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>Reflective Perspective - Chris Alcock  &amp;raquo; The Morning Brew #195</title><link>http://blogs.msdn.com/ericlippert/archive/2008/10/06/preventing-third-party-derivation-part-two.aspx#8982874</link><pubDate>Tue, 07 Oct 2008 10:04:44 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:8982874</guid><dc:creator>Reflective Perspective - Chris Alcock  &amp;raquo; The Morning Brew #195</dc:creator><description>&lt;p&gt;PingBack from &lt;a rel="nofollow" target="_new" href="http://blog.cwa.me.uk/2008/10/07/the-morning-brew-195/"&gt;http://blog.cwa.me.uk/2008/10/07/the-morning-brew-195/&lt;/a&gt;&lt;/p&gt;
</description></item><item><title>re: Preventing third-party derivation, part two</title><link>http://blogs.msdn.com/ericlippert/archive/2008/10/06/preventing-third-party-derivation-part-two.aspx#8984154</link><pubDate>Tue, 07 Oct 2008 13:50:57 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:8984154</guid><dc:creator>Anders Borum</dc:creator><description>&lt;p&gt;Great post; also looking forward to the forthcoming series Eric.&lt;/p&gt;
</description></item><item><title>re: Preventing third-party derivation, part two</title><link>http://blogs.msdn.com/ericlippert/archive/2008/10/06/preventing-third-party-derivation-part-two.aspx#8985907</link><pubDate>Tue, 07 Oct 2008 19:31:37 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:8985907</guid><dc:creator>Erik</dc:creator><description>&lt;p&gt;Ooh, you're mean, hiding that little snippet at the end there... *glower*&lt;/p&gt;
</description></item><item><title>Blog Carnival #8</title><link>http://blogs.msdn.com/ericlippert/archive/2008/10/06/preventing-third-party-derivation-part-two.aspx#8986681</link><pubDate>Tue, 07 Oct 2008 22:03:07 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:8986681</guid><dc:creator>IHateSpaghetti {code}</dc:creator><description>&lt;p&gt;Unit testing Udi Dahan wrote a post about unit testing - Unit Testing for Developers and Managers Architecture&lt;/p&gt;
</description></item><item><title>re: Preventing third-party derivation, part two</title><link>http://blogs.msdn.com/ericlippert/archive/2008/10/06/preventing-third-party-derivation-part-two.aspx#8986691</link><pubDate>Tue, 07 Oct 2008 22:04:13 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:8986691</guid><dc:creator>Ian Marteens</dc:creator><description>&lt;p&gt;There could be an even simpler technique for preventing third-party derivation: the sixth visibility level supported by the CLR (and by some languages as Oxygen). The CLR supports both &amp;quot;family or assembly&amp;quot; (this is C#'s &amp;quot;protected internal&amp;quot;) and &amp;quot;family AND assembly&amp;quot;, not supported by C#.&lt;/p&gt;
&lt;p&gt;Ok: not all virtual methods are protected, but protected ones could be marked &amp;quot;protected and internal&amp;quot;, so they could only be overridden from inside the defining assembly.&lt;/p&gt;
</description></item><item><title>re: Preventing third-party derivation, part two</title><link>http://blogs.msdn.com/ericlippert/archive/2008/10/06/preventing-third-party-derivation-part-two.aspx#9033635</link><pubDate>Mon, 03 Nov 2008 19:04:31 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9033635</guid><dc:creator>Joe Mele</dc:creator><description>&lt;p&gt;Hi Eric,&lt;/p&gt;
&lt;p&gt;Thanks for the post. I have similar problem. I want to distribute a SDK that only *licensed* developers can extend. &lt;/p&gt;
&lt;p&gt;Do you have any suggestions?&lt;/p&gt;
&lt;p&gt;Joe Mele&lt;/p&gt;
</description></item><item><title>re: Preventing third-party derivation, part two</title><link>http://blogs.msdn.com/ericlippert/archive/2008/10/06/preventing-third-party-derivation-part-two.aspx#9033690</link><pubDate>Mon, 03 Nov 2008 19:21:04 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9033690</guid><dc:creator>Eric Lippert</dc:creator><description>&lt;p&gt;Sure. First, get a lawyer. Have the lawyer write a EULA. Ship your SDK with a EULA that specifies that the classes may not be extended without license. Then have your lawyer sue the pants off anyone who violates your EULA.&lt;/p&gt;
&lt;p&gt;I would characterize this as a human relations problem, not a technical problem.&lt;/p&gt;
</description></item><item><title>re: Preventing third-party derivation, part two</title><link>http://blogs.msdn.com/ericlippert/archive/2008/10/06/preventing-third-party-derivation-part-two.aspx#9033811</link><pubDate>Mon, 03 Nov 2008 19:45:28 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9033811</guid><dc:creator>Joe Mele</dc:creator><description>&lt;p&gt;lol &lt;/p&gt;
&lt;p&gt;Is that your approach to all software licensing? &amp;nbsp;:) &lt;/p&gt;
&lt;p&gt;I am working on a solution using SoftAnchor from uniloc. Just looking for another perspective/ideas.&lt;/p&gt;
&lt;p&gt;thanks&lt;/p&gt;
&lt;p&gt;Joe Mele&lt;/p&gt;
</description></item></channel></rss>