Sign in
|
Join
ISerializable - Roy Osherove's Blog
Unit Testing, Agile Development, Leadership & .NET - By Roy Osherove
This Blog
Home
About
Syndication
RSS
Atom
Comments RSS
Search
Go
Navigation
Home
Blogs
News
My new book is out!
The Art Of Unit Testing
Buy and read it as I write it.
I work at:
Your ad here
The Art Of Unit Testing Book
Roy's Cool Tools
Subscribe!
Subscribe to ISerializable by Email
About
Hire me
Ask me
On my bookshelf
About me
Ego trip
Roy's Tools
5 Whys - a blog for team leaders
Key.bo - a search engine wiki for keyboard shortcuts
unit testing
ruby styff
All Developer Songs
It's Time for Violence
Que Sera Sera
Articles
3: Oops! Typed Datasets
Are
scalable!
4: Introduction To Regular Expressions
5: Practical Parsing Using Groups in Regular Expressions
6: UI Threading Helper Classes
Make Your App Support Plugins 2 - Dynamic Search (MSDN)
Winforms Data Binding Lessons Learned
Make Your App Support Plugins (MSDN)
1: Introduction to Typed Datasets
2: Typed Datasets Are No Silver Bullet
My articles on MSDNAA
7: Solving VS.NET Debugger Problems
Make your log files searchable using Regex and the XML classes (MSDN)
Introduction to TDD with NUnit
Fun with Unit Tests – Testing abstract classes
New: Creating a generic Site-To-RSS tool
.Net scripting
- the practical way
Simplified Database Unit testing using Enterprise Services
Creating custom test attributes easily with NUnit 2.2.1
Cool tools every .Net Dev should be aware of
Cool Tools every .Net developer should be aware of
New: The case for staged delivery and Agile methodologies
My .Net Deep Dive lectures on video
New: Defensive event publishing in .Net, part 1
Test Feasibility Matrix
Depenedency Breaking Issues
*new* Achieving And Recognizing Testable Software Designs – Part I
Favorite Blogs
The Morning Brew
Martin Fowler
Scott Hanselman
Joel On Software
.NET Weblogs
Microsoft Israel Community
The Runtime
Daniel Moth
Oren Eini
Jimmy Bogard
CodeBetter
Dustin Campbell
Guy Kawasaki
Stephen Toub
Research @ Intel
Udi Dahan
The Typemock Insider
My Projects
Vs.Net Settings import.export Add-in
SchemaHelper - auto-detect & create data relations
Proxy handling using ProxyFactory and ProxyInfo
BackgroundWorker implementation
XtUnit: An Unofficial Unit Testing Extensibility Framework - Add new attributes to NUnit or MbUnit e
Intercetpion Application Block
Extensibility Application Block
The Regulator
VS.Net 2003 registry tweaker
My Tools page
Regular Expressions
RegEx Lib
Expresso
Regex Blogs
Sites : .Net
.Net Tools List
.NetWebLogs Forums
Winforms FAQ
.Net Debugging Resources
.Net WebCasts & Others
.NetWeblogs Archive
MSDN Magazine
Design Patterns in C#
.Net Rocks Radio
.Net Resources
Howto: .Net common tasks
VB.Net blogs on MSDN
.NetSlackers
Sites : Misc
Regular Expression Library
MSR Downloads
Win2k3 Tweak Guide
About Microsoft Interviews
Tech Interview Riddles
Feedster
Amazon Light
C:\Utils
Sites : Unit Testing & XP
NUnitASP
Tips and techniques with NUnit
NUnit
NUnit Addin
XProgramming
MSDN Mag:Simplify Data Layer Unit Testing using Enterprise Services
Tags
.NET
.Net 2.0
.Net Original
.Net Quotations
.NetWeblogs Site
Addin Contest
ADO.Net
Agile
Agile Israel News
Agile Related
altnet
altnetconf
altnetisrael
Architecture
Art Of Unit Testing
ASP.NET
BDD
Blogging
C#
CLR
Community
Community News
Cool Articles
Cool sites
Cool Tools
Extensibility
Family
FeatureFocus
Free book chapters
General Software Development
Interview
Lean
Mobile
MSBuild
NDC09-Video
Off Topic
Open Source
Other
Product Reviews
Project Management
racer
Recommended books
Reflection
Regex
Regular Expressions
review
Security
Sharepoint
Silverlight
SOA
Songs
SQL Server
tdd
Team Agile News
Team System
TechEd 05
Testing Guidelines
TestReview
Threading
Tips & Tricks
Typed Datasets
Typemock
Unit Testing
Visual Studio
web
web services
WebCast
Windows Forms
WinFX
Recent Posts
How to: Move your blog off of weblogs.asp.net (aka ‘This Blog has moved’)
test – ignore
Bounty: 500$ is you can convert my blog to squarespace
Join me for a live webinar on unit testing with Isolator++ this thursday
What’s coming in Test Lint 1.5
Archives
November 2010 (2)
October 2010 (4)
September 2010 (4)
August 2010 (3)
July 2010 (2)
June 2010 (5)
May 2010 (6)
April 2010 (6)
March 2010 (4)
February 2010 (5)
January 2010 (11)
December 2009 (7)
November 2009 (7)
October 2009 (5)
September 2009 (6)
August 2009 (21)
July 2009 (7)
June 2009 (11)
May 2009 (13)
April 2009 (5)
March 2009 (21)
February 2009 (4)
January 2009 (2)
December 2008 (5)
November 2008 (6)
October 2008 (13)
September 2008 (4)
August 2008 (13)
July 2008 (19)
June 2008 (5)
May 2008 (17)
April 2008 (11)
March 2008 (13)
February 2008 (16)
January 2008 (21)
December 2007 (8)
November 2007 (18)
October 2007 (17)
September 2007 (15)
August 2007 (19)
July 2007 (18)
June 2007 (33)
May 2007 (16)
April 2007 (10)
March 2007 (15)
February 2007 (10)
January 2007 (11)
December 2006 (22)
November 2006 (18)
October 2006 (19)
September 2006 (30)
August 2006 (19)
July 2006 (27)
June 2006 (26)
May 2006 (32)
April 2006 (15)
March 2006 (20)
February 2006 (33)
January 2006 (23)
December 2005 (22)
November 2005 (41)
October 2005 (21)
September 2005 (7)
August 2005 (28)
July 2005 (41)
June 2005 (60)
May 2005 (14)
April 2005 (51)
March 2005 (31)
February 2005 (17)
January 2005 (63)
December 2004 (45)
November 2004 (35)
October 2004 (28)
September 2004 (36)
August 2004 (21)
July 2004 (44)
June 2004 (63)
May 2004 (62)
April 2004 (78)
March 2004 (64)
February 2004 (55)
January 2004 (67)
December 2003 (34)
November 2003 (67)
October 2003 (68)
September 2003 (113)
August 2003 (56)
July 2003 (112)
June 2003 (71)
May 2003 (136)
April 2003 (52)
March 2003 (81)
February 2003 (77)
Why is VS.Net Add-in architecture so overly complicated?
My blog has moved.
You can view this post at the following address:
http://www.osherove.com/blog/2004/4/29/why-is-vsnet-add-in-architecture-so-overly-complicated.html
Published
Thursday, April 29, 2004 11:27 PM by
RoyOsherove
Filed under:
.Net Original
Comments
Thursday, April 29, 2004 7:59 PM by
HumanCompiler
#
re: Why is VS.Net Add-in architecture so overly complicated?
I don't know this for a fact, but I believe I've heard/read/made up in my own mind/etc that the fact that Office is still COM is why VS.NET is as well, because all the menuing and all that I believe is directly taken from Office. I could be wrong, but that's my guess and I'm sticking to it!
My next thought was, hhhmmm...maybe performance? But then that gets you thinking...what does that say about managed code? :P
Where's Josh on this one? :P
Thursday, April 29, 2004 7:59 PM by
AndrewSeven
#
re: Why is VS.Net Add-in architecture so overly complicated?
For quite some time I have thought that it has to do with reuse, that a lot of VS.Net is not written in .Net or managed code.
I think DTE is an example...
Thursday, April 29, 2004 8:57 PM by
Addy Santo
#
re: Why is VS.Net Add-in architecture so overly complicated?
My guess (which isn't any more authorative than anyone else's) is that the VS.NET is built heavily on the previous VS 6 codebase, which was built on the one before it, etc. When most of your code base is 3-4 years old (and probably has certain artifacts dating back even more) you don't have lots of architectural fliexibility.
Thursday, April 29, 2004 8:59 PM by
secretGeek
#
re: Why is VS.Net Add-in architecture so overly complicated?
hey Roy - i've got some addin suggestions on my blog, specifically for your competition. No time to code any myself.
DTE, by the way, is all legacy code, wrapped up for use in VS.net. The design decision behind this, I think, is that until VS.net was a more stable product (ie after two or three versions) it wasn't worth rewriting the extensibility components. Craig Skibo talks about it in that book, "Inside Visual Studio .Net" -- but I don't have it on me at the mo'.
Best of luck with the competition.
Leon Bambrick
Friday, April 30, 2004 9:38 AM by MLT
#
re: Why is VS.Net Add-in architecture so overly complicated?
Certain core parts of the basic plug-in architecture of the VS extensibility model will be changing in the Whidbey. Most of the conjectures here are, for the most part, accurate in one way or another. Heavy VS6 foundation. Same interfaces in EnvDTE as you may recognize when previously building COM add-ins. The menus (context menus, commandbars, etc) are all from Microsoft.Core.Office interop namespace. I concur that it is overly complicated, but when it does work well, just very annoying at times.
Notice that VSIP Extras came much later than VSIP, so even the uber-integration APIS provided by VSIP followed the same legacy/unmanaged code route first, then VSIP extras brought in managed goodies (extras by name).
Friday, April 30, 2004 12:44 PM by
jledgard
#
re: Why is VS.Net Add-in architecture so overly complicated?
There is a lot of truth in the comments here. For the definitive answer I would suggest pinging
http://blogs.msdn.com/craigskibo/
since he is a developer on the extensibility team. Essentially the COM feel is truely becuase VS.Net is, at its core, a COM app itself. While more an more components are written in managed code we have not felt compelled to scrap the investment we've made in the shell platform just yet. Craig could also comment about some of the things that are being done in Whidbey to make the process easier.
Saturday, May 01, 2004 8:49 AM by
Patrick Steele
#
re: Why is VS.Net Add-in architecture so overly complicated?
Why doesn't VB.NET have Edit & Continue?
Why doesn't C# have generics?
Why do winforms still wrap the old Win32 APIs?
I think it's just a time issue. Sure, they could have made a totally managed VS.NET add-in architecture, but that might have delayed the release of .NET for 6 or 9 months (or more?).
You can't get everything in the first go-around. :)