Don't forget, office is the cash
(blinking in astonishment)
Um, C# is a language. I never said it was a "cash cow." It is simply a
programming language, but THE central programming language of the .Net
platform. Microsoft doesn't make ANY money from C#, but they are making some
incredible inroads with the .Net platform. I DID say that the .Net platform
is used for a heck of a lot more than interacting with Office apps. As for
Office being THE cash cow at Microsoft, well, forgive me for restraining my
laughter. Office certainly is A "cash cow" at Microsoft. However, writing
..Net interop with Office certainly is not. And it's not likely to be in the
near future. Remember, the vast majority of Office users never program with
Office. They may create a macro now and then, but they are just users, not
programmers.
it's good to see that Microsoft frontliners are
no longer thinking along your lines, they indeed see office as platform
that
needs tight integration with the .NET framework.
Again, you're thinking backwards. They see OFFICE as a platform that needs
tight integration with the .Net Framework, NOT the other way round. And for
good reason. In fact, Microsoft is heavily invested in the .Net Framework,
and is steering most of its software fleet in that direction. There are
excellent reasons for this, which are too many to enumerate here in the
short time I have to do this stuff.
So your 'few' is slightly less than 50% of .NET developers (2
million from 5 million .NET programmers).
Interesting statistic. I wonder where you got it from? Perhaps there are a
large number of programmers that work with Microsoft Office to a certain
extent. I can guarantee you that the vase majority of those programmers
don't spend the majority of their time doing so.You might want to step away
from the Office marketing hype and take a wide look at the overall Microsoft
strategy. They have far more areas where they want to compete than Office,
and much more of a long-term strategy than is dreamt of in your philosophy,
Horatio.
To know what is, these days, is to know not much. It is far more important
to know what will be. Things are changing very quickly now. In fact,
Microsoft is waging an important battle in the Operating System market share
(Windows is probably THE "cash cow" at Microsoft, if anything), and the .Net
platform is part of that strategy. They are also waging a great battle in
the server software market place, and that is also dependent upon the .Net
platform, and its success or failure. And of course, they are competing with
great gusto in the programming platform and technology marketplace.
Microsoft has been listening to complaints about C# lack of friendliness
to
office programming by the way. I fully expect them to do something in the
next release once the noise becomes unbearable.
The success of the VSTO initiative absolutely depends on it.
The success of the VSTO initiative and the success of Office are two
entirely separate things. The success of Office is a long-term goal, and
will depend largely upon many of the changes that are beginning to be made
in the software infrastructure of the Office apps. In a few short years,
there will be no need for Interop assemblies to work with Office
applications, and particularly, with Office documents. So, I wouldn't bet on
Microsoft making any radical changes in the underlying programming
philosophy of the .Net platform to save VSTO. Certainly, they want to get
their investment back on it, and they probably will. But the VSTO that you
see now is not the VSTO that is already in the works, at least on the
drawing board at Microsoft (so my crystal ball tells me). The long-term
success of Office will have little to do with VSTO; it will depend largely
upon the changes that Microsoft is already implementing in Office, and NOT
upon changes made in the .Net Framework to accomdate VSTO. I wish I could
discuss this in more detail, but I do have an NDA to adhere to.
Anyway, that's my story and I'm stickin' to it! ;-)
--
Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
Alvin Bruney - ASP.NET MVP said:
Office is not written in .Net.
I don't recall saying that it was.
So, you're saying that the C# language specification should be changed to
Yes, that is what I am saying. The office movement is the biggest wave to
hit the developer shores in a while. It would be well worth Microsoft's
invest to cater to the demands of such a movement. If microsoft intends to
woo VBA developers into managed code development, the effort needs to be
authentic which means building internal support into the tools used to
build
office development. If that means bending or breaking C# language
specification, then that is what must be done. At the end of the day,
profitability absolutely depends on it. Don't forget, office is the cash
cow. not c#.
Office development is not what the .Net platform
That is not true at all. .NET platform is for .NET development.
Currently, office development can be done with .NET. In fact the
integration
is built right in with
VSTO. That type of mentality is what caused .NET to ship without authentic
internal support for Office technology - read vsto 2003 as a lame effort
to
repair the blunder. However, it's good to see that Microsoft frontliners
are
no longer thinking along your lines, they indeed see office as platform
that
needs tight integration with the .NET framework.
sure it comes in handy for a few developers out there from time to time.
It is just more than a few developers. The target is well over 2 million
developers by conservative estimates and they do it far more than from
time
to time. So your 'few' is slightly less than 50% of .NET developers (2
million from 5 million .NET programmers).
Microsoft has been listening to complaints about C# lack of friendliness
to
office programming by the way. I fully expect them to do something in the
next release once the noise becomes unbearable.
The success of the VSTO initiative absolutely depends on it.
--
Regards,
Alvin Bruney [MVP ASP.NET]
[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @
www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------
Kevin Spencer said:
Office is not written in .Net. VSTO is a set of Primary Interop Assemblies.
So, you're saying that the C# language specification should be changed to
accomodate the use of a narrowly specialized set of Interop assemblies
for a
set of applications that have loosely-typed COM interfaces?
Office development is not what the .Net platform was designed for. Most .Net
developers never touch it. VSTO is a set of Office extensibility tools. I'm
sure it comes in handy for a few developers out there from time to time.
However, as VBA is the language of Office, it seems more logical to use
VB.Net to develop with the VSTO than to use C# and complain that it is hard
to write wrappers for VSTO with it.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
A watched clock never boils.
Alvin Bruney - ASP.NET MVP said:
The reason for optional parameters is not just a fad or a nice to have
feature. VSTO programming is significantly challenged in C# because of the
need to keep entering parameters. Like it or not, that has disuaded
many
C#
developers from going with the technology. I contend that most simply have
a
passing interest because of this lack of support.
VB on the other hand suffers no such set back. For instance, some
method
calls require 30+ parameters where only 1 is required
VB
ThisApplication.ActiveDocument.Add("filepath.doc) in vb becomes
C#
ThisApplication.ActiveDocument.Add("filepath.doc", Type.Missing ....30
times).
Microsoft's current approach is to promote the use of C# wrappers
around
these method calls. I think they need to do more to help C# developers by
promoting internal support for parameters. I certainly do not
appreciate
spending my development day writing wrappers around methods. What's the
point of pushing VSTO so hard without complete support for it in the
darling
C# language? Seems to me like this wasn't thought all the way thru!
By the way, there are some of us who simply will not program in VB.
Period!
We either take the abuse in C# or go back to VBA programming for
developing
office applications. There is more than a majority sharing this opinion
for
sure. And it is an important opinion because it will determine wide spread
adoption for technologies based on Office.
--
Regards,
Alvin Bruney [MVP ASP.NET]
[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @
www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------
Kevin,
The reason that C# doesn' t have support for optional paramaters is that
they don't exist.
Actually the reason given most of the time is that optional parameters
with default values have versioning problems.
http://blogs.msdn.com/csharpfaq/archive/2004/03/07/85556.aspx
I'll buy that for public methods but still think it would be
convenient to have support for optionals for internal use.
VB.Net creates the illusion that they do, by creating
overloads behind your back.
No it doesn't. The CLI definitely supports real optional parameters.
Mattias
