.Net RoadMap (any)

Topic

New Reply

VB and VBA developers may find this link useful.

Reply | Quote

Replies

Kevin,

Interesting read, but what’s missing from the point of view of Office/VBA developers is ‘Office programmability’.

Assuming Office 11 is still VBA-powered, and not due to be released until 2003, then it sounds like 2005 at earliest before a released version of Office will permit programmability with VB.Net.

This raises interesting questions for developers (like me) who mainly work with Office but who may want to expand their understanding of VB and perhaps branch out into VB development. I know that every bit of VB that I’ve been able to learn has translated into better ability with Office VBA.
However any study directed to VB.Net now, is not going to be applicable to Office for at least three more years.

So where does an Office developer who wants to improve their skills, direct their efforts? – learn more VB (for the indirect benefit of better understanding of Office VBA), or learn VB.Net because that’s the way everything is going eventually.

I’ve got to conclude the answer is: both!

Gary

Reply | Quote

>>So where does an Office developer who wants to improve their skills, direct their efforts?

Here’s my personal addition to the “roadmap”. Call it the Kevin Edition Roadmap Addition:

If you are developing Office applications that are essentially turn-key systems (global
addins that provide added functionality or a business solution) then you can

1) jump on the .Net bandwagon now and built COM addins for Office using .Net (C# or VB).
2) create COM addins of Office using the MOD. This is Visual Studio 6.0 (VB6) based development.
3) use VBA, the API, OLE/COM, etc. to build the apps.

We’re going with #1 because it brings you and your apps into the world of full-on OOP and keeps
you at least 10 years ahead of the obsolescence steam roller. Besides, there is actually a little
money left for this.

If you are developing intelligent templates, macros and the like for a department here
and a department there, stick with VBA which will be supported even in Office 12 (as will
WordBasic!)

As far as “learning more VB” goes, forget it. Learn .Net. Your VB skills are not lost in
.Net if you choose VB.Net as your code lingo. But even if you jump to C# (as I am), it
won’t take long to get up to speed with some good training materials.

Reply | Quote

IMO for Office developpers, 90% is knowledge of the applications, and only 10% knowledge of the programming language.

I’m not a programmer — as far as my stuff goes, it won’t matter much to change if necessary. The difference seems much smaller this time than it was from WordBasic to VBA.

What would interest me if I was a professional: Will MS make sure that my code runs five years from now? And if I want to port, will it help everybody with the conversion of old code?
I would bet my on it, though there seem to be quite few who usually are better informed that wouldn’t.

Klaus

Reply | Quote

VB code is *not* really compatible with .Net (I know, to an extent it is). Any VB project will
require work to get it to compile and run on the .Net framework. Plain and simple.

So, if that “upgrade” established a Microsoft track record, then NO your code will not run in 5 years.
However, I do not believe the transition from VB to VB.Net makes for a trackrecord. It does
make for a (to use a trite buzzword) quantum shift in development practice that will not
change in five years. I think it’s save to say that any .Net code created today will compile
and run effortlessly on the .Net framework of tomorrow. If there’s anything that comes
close to insuring your code will run in 5 years, it’s the .Net Framework.

There’s about 6

Reply | Quote

Kevin, you’re a raving optimist! You know those extensibility libraries included in Office and VB? That’s what makes code from a couple of versions ago run in your current versions. Why should the leopard change its spots just because .Net is the new be-all and end-all?

Reply | Quote

A number of things MUST change in a .NET-ized Office.

For example, all .NET languages require that arrays have a lower bound of 0.
Excel will really be impacted.

Variant data type is gone.

The change is actually greater than going from WordBasic to VBA, but I expect that MSFT will have a better upgrade engine for VBA to VSA, so the upgrade may be easier than from WB to VBA.

Reply | Quote

Arrays starting at zero and no more variant data type? Then I would have to change next to nothing in my code.

For some more changes see Karl E. Peterson’s list, or Microsoft’s migration paper.

Nothing in there that looks like a quantum leap to me. From what I’ve seen, we will get a nice new language that does away with some old stuff and makes cross-language development easier, but nothing like the conceptual change that occurred between WordBasic and VBA.

Pretty soon there’ll be .NET mouses and keyboards and what not, and perhaps even the next Office (with VBA) will be called Office.NET.

Though I must admit I have scarcely looked into VB.NET or the .NET framework yet, much of the .NET hype seems like a lot of … eerm … hype?

Since the next version of Office will still have VBA, and at least the next two versions after that will almost surely support it, I’m in no terrible hurry.

Klaus

Reply | Quote

It’s a lot more than hype.

Apress has a book on upgrading VB to VB .NET.
MSFT Press has a book on upgrading from VB to VB .NET
Apress has a book that compares VB, VB .NET and C#.

Obviously, there’s gonna be books on convedrting VBA to VSA, but I am guessing that if one learns how to upgrade from VB to VB .NET, one will be ahead of the game.

The MSFT paper just scratches at the surfac.

Karl Peterson’s list is misleading.
For example, it states that MsgBox and Debug.Print are not supported. The functionality is supported, but the syntax is different.
If one does not want to worry abould changing syntax, one can always program in assembly language.

Reply | Quote

Kevin,

If I were developing standalone applications, or Office add-ins that function like standalone applications, then I would jump to be able to do these using VB.Net.

But virtually all of what I do (to date anyway) is develop ‘intelligent templates’ (and I’m guessing 90%+ of users of VBA on this Lounge are in this category) which means sticking with VBA.

So while I’m onboard with your advice to learn VB.Net rather than VB – for doing things that used to be done using VB – the introduction of VB.Net does leave the Office developer who wants to expand their skills, in a bind:
Anything I learn of VB.Net today, is not going to be applicable to my day to day work, for at least three more years.

Since Office programmability with VBA was introduced, Office development and VB development have been joined at the hip, sharing a common language, and there was a high degree of interchangeability of skills between the two.
Now with Visual Studio.Net, and VB.Net or C# superseding use of the VB language for what was previously ‘VB application development’, that conjoinment between VB and VBA is being ripped apart. What makes this divergence difficult to plan for is that it is only expected to be temporary – if Office 12 is programmable using Visual Studio.Net, then things will be rejoined again – in three years.

Just as soon as becomes possible to program Office using VisualStudio.Net, it has to make sense for VBA developers to jump to VB.Net (or C# if you prefer), because that is the direction everything is going. Even if VBA continues to be supported for a few more generations of Office, there’s little point in sticking with it as VBA will become increasing ghetto-ized.

It’s the temporary divergence between Office development (VBA), and Visual Studio-based application develpment (VB.Net/C#) that makes skills development planning really tough right now for Office developers. It still seems to me that I will need to spend the next three years developing my skills in both.

Gary

Reply | Quote

In addition to language incompatibilities, I expect there may be a few incompatibilities because of changes in the object model.

At least I hope that some rather flaky design decisions will be remedied.

As an example, the hoops you have to jump through to make a Word macro work in all story ranges come to mind.
Another change on my wish list would a proper distinction between paragraph styles and character styles (which really should be in two different collections).
I’m sure there are quite a few other areas that could benefit from changes in the object model.

Klaus

Reply | Quote

Your point is well taken: VBA-only programmers will not be able to
“move on” to the .Net world until VSA or VBA.Net is bolted into Office.

One environment we haven’t seen much in the Lounge is the world of COM addins.
I’m currently experimenting with the idea of converting all “intelligent templates” into COM addin driven
templates. In fact, the entire “award-winning” app may soon be overhauled into a COM addin on steriods.
The idea is to base all documents on 1 template: normal.dot (or as I use and I think you use
a “FirmNormal.dot”). We deploy documents from a set of about 3 dozen base templates from which
the creation of 500+- documents types are automated. Since I took the global addin approach to begin
with, the move to a COM addin should not be too challenging. Nevertheless, we’re still thinking it through.

I’d like some feedback on whether you think this is possible. We’re talking about storing the boilerplate
language as well as all autotext currently deployed during the document creation process in XML files or db records.
What ramifications do you see in such a move?

Reply | Quote

> We’re talking about storing the boilerplate language as well as all autotext currently deployed during
> the document creation process in XML files or db records. What ramifications do you see in such a move?

Preserving rich text could be a challenge. Certainly anything more complex (such as a table) would be extremely tricky to handle outside of the AutoText context. Maybe XML is up to the challenge… [skeptical look]

Reply | Quote

Thanks for chiming in Jefferson. Appreciate your insights. So far, Word 11
converts everything visible to XML. It does not save templates as, say, an XMT
file as one might expect. In fact any autotext in a template is stripped out if you save
the template as XML. Tables present no problem.

I do think MS needs to do something about the autotext situation though. XML is not
really a native file format if it can’t store autotext (or provide some other means of
storing text like autotext).

Reply | Quote

Interestingly, OpenOffice.org/StarOffice uses a zipped XML file format for both documents and templates. You can see the general idea in the attached, which was set up with my common margins and settings and one test macro.

I couldn’t figure out how to store AutoText in a document/template; it seems to be stored in two (rather slow) database or XML files, one shared and one personal. (When I converted a Word 2000 template and chose Save As, the AutoText was nowhere to be found. Hmmm…)

Reply | Quote

Kevin,

I’ve never created a COM add-in so don’t have too much useful feedback. Where I’ve read about this, the suggestion was that COM add-ins are most useful for providing functionality that may be used by more than one Office application.

As far as storing boilerplate language in a db, of course that’s feasible. This will make the global template much smaller, but on the other hand, accessing the data from a db will be much slower than accessing data that’s hard-coded into the template.
Where I work, the decision was made a couple of years ago to put as much global data as possible, into a db rather than the template(s) (or .ini files as we were doing previously). The main benefit I think is that it’s much easier to deal with (and maintain) the data if it’s all in one place.

I’m curious as to what you perceive to be the benefits of moving the code from your global template into a dll.
It seems that developing, testing and debugging (and possibly deployment/version control) will be less handy with the COM add-in than just keeping the code in a .dot.

Gary

Reply | Quote

One advantage: Code in a DLL runs MUCH faster than code in a template.

Reply | Quote

Kevin wrote: >>I’m currently experimenting with the idea of converting all “intelligent templates” into COM addin driven templates. … a COM addin on steriods. The idea is to base all documents on 1 template: normal.dot (or as I use and I think you use a “FirmNormal.dot”). We deploy documents from a set of about 3 dozen base templates from which the creation of 500+- documents types are automated. <<

Hi Kevin,

I have roughly 100 templates in Word presently, many of which are just for letters, differing only slightly in actual content. Now we want to greatly enhance the functionality of these templates, to allow content and metafile information (such as description and document 'type' in the DOC file Properties) to be created and populated based on data coming from a database.

As you said in this November 2002 post, I also am considering whether boilerplate text ought to come from a (different) database, or reside in XML files. I've considered having the "master" copies reside in the database, and a process to copy new or changed masters down to XML or TXT files residing on the client. This approach has all the advantages of databases, including replication between sites, as well as strong security and rights on the source information in the masters, but allows the user to work offline.

One reason why rights on the master boilertext is an issue, is that we've fantasized about having a user-friendly frontend where selected powerusers could create boilerplate and make it available to their colleagues. One reason this is so appealing is that it would take the IT department out of the business of making changes to content in templates. It would also let users in different countries around the world devise the boilerplate for their country in their local language, again without my involvement. I'm imagining an intranet front-end to the database for the boilerplate masters.

I'm a bit confused about the sameness and difference between things like OLB files, Type Libraries, DLLs, COM Add-Ins, when it comes to taking functionality I've been accustomed to putting into Normal.DOT (which can be a deployment headache), and instead trying to encapsulate it in such assemblies. I have the notion that COM Add-Ins may be needlessly complex for code meant to run in Word only. Did you use COM Add-Ins in the end? Isn't a plain vanilla DLL simpler to call from Word and develop?

I am doing all new development in VS.Net, with the intent to simplify future revisions.

I'm curious what approach(es) you've taken as you progressed with your project. This has become a long message. Sorry for that. In short — I'm very curious about nearly anything you feel willing to share about the approach you've taken to your project.

Reply | Quote

Just responding to this part –

> Did you [Kevin] use COM Add-Ins in the end? Isn’t a plain vanilla DLL simpler to call from Word and develop?

A COM Add-in implements an interface that makes Word directly aware of it. If you create a stand-alone DLL, you still need to distribute something that makes Word aware of it and accesses it. The only DLLs I’ve ever created were COM Add-ins, and yes, there are lots of rough patches in going from VBA development to DLL development, but without the add-in piece, I think you would have more incrementally more integration and deployment headaches.

Reply | Quote

Geoff,
I responded yesterday in a post that went bye-bye before I could click Post It. Bummer.

Try to be brief:

We built a COM addin using the Office XP PIAs and C# as the language. Mucho trouble with
the PIAs, but my partner did an excellent job of “discovery” on his own. The docs for the PIAs
are almost non-existent (there are a few MS articles out there). All the template language stayed in autotext because Office 10
XML isn’t so hot. And Office 11 templates still have to be .dot files, not XML. Moving the
pieces to XML in a database might be a good move later when Office 11 XML proves itself.

To simplify your .Net Office dev, wait for VSTO in Office 11. If you must move ahead now, you’ll
plod along in the footsteps of yours truly. (note the circular paths and deadends). However,
please note that the app is now in beta and moving along. It’s 90% done but that last 10%
is dragging the project along rather slowly.

BTW, if anybody needs to know how to disable an installed COM add-in (without having to uninstall it),
just read on. There’s a regkey under HKLMSoftwareMSOfficeWord(or whathaveyou) hive called Addins. Your app will have a hive and it’ll have
a key dWORD named LoadBehavior. Simply change LoadBehavior to 8. The addin stays installed, but disabled.

Reply | Quote

there’s an interesting article here:
http://www.mssmartsolutions.com/features/2…a200302dk_f.asp%5B/url%5D

greetings,

Reply | Quote

Hi Kevin,

Thanks for your response, and taking the time to rewrite it (which is always worse than writing something the first time), and the fact that you rewrote it I appreciate it all the more.

I live with a few realities: Foremost, in my firm, we have Hummingbird’s DOCS Open 3.9 (formerly PCDocs) document management system. This means that users can save and open and share documents which are stored and managed on a fileserver, and there is a ODMA-compliant frontend with SQL Server behind the scenes controlling document access.

Due to our commitment to DOCS Open, the EARLIEST I could expect to have Office 11 in all 30 offices would be March 2005. Unfortunately DOCS Open 3.9 (the current version) works solely with Office 2000 (9.0) and not Office XP (10). We’re at least a year from upgrading Office at all, and Hummingbird upgrades of DOCS Open lag a given version of Office by 6 to 9 months, and deployment to our 30 offices worldwide takes about a year. Assuming Office 11 comes out in June 2003, my Office 11 platform won’t exist until March 2005, and if Hummingbird isn’t ready when we are starting our rollout, it could well be Office 10 that gets rolled out for March 2005.

Thus — my only option is Office 2000 (9.0) for the near future. For Office 2000, There is no PIA (Primary Interop Assembly) like the one you used for Office XP (10).

Moving ahead now, doing my development in VS.NET, but without the PIA, still leaves me plodding in your footsteps, doesn’t it? The method of Interop (PIA vs. VS.Net’s default CCW) doesn’t really impact the principal code and logic for document creation, and getting Word tap-dancing, does it?

Does the code in your COM Add-In provide functionality that automates Word?
In other words, presumably your COM Add-In acts as a code library with functions which returns values and information; but does it also accept a pointer to the ActiveDocument and get Word to make the actual changes in the document?

I ask this (possibly) naive question because:
* I am used to having everything in Normal.DOT and don’t worry about what-calls-what
* One of the articles someone offered a link to makes a big deal about whether you’re working with a CCW (COM Callable Wrapper) which allows a .NET assembly to be called from Word; OR whether you’re working with a RCW (Runtime Callable Wrapper) which allows a .NET assembly to call the Word.Application object. The article was http://www.mssmartsolutions.com/features/2…a200302dk_f.asp and I am not clear at all as to which one a COM Add-In would actually be. It feels like COM Add-Ins written in .NET would be both.

I hope these questions aren’t dumb.

Reply | Quote

Geoff, it seems that the best way to start is to try to add references to some of the Office 2000 COM libraries to a .NET project and see if they are usable. The article suggests that will work a lot of the time:[indent]

---

When you add a reference to a .NET project, the Add Reference dialog box has a COM tab that lists all the COM objects installed on the local machine. The process is about as painless as adding a COM reference to a Visual Studio 6 or VBA application.

---

[/indent].NET Does Office

Reply | Quote

Geoff,

>>The method of Interop (PIA vs. VS.Net’s default CCW) doesn’t really impact the principal code and logic for document creation, and getting Word tap-dancing, does it?

Without the PIAs, I suspect you’ll be limited if for no other reason than you’ll be without the intellisense, which even with the PIAs
is all too often not very intelligent. In fact, it’s downright undocumentedly frustrating. Check out the “AutoWord Sample” solution in the Visual C# Samples
that install with VS.Net. I’m not sure if there’s a VB.Net equivalent.

>>Does the code in your COM Add-In provide functionality that automates Word?

Yes.

>>does it also accept a pointer to the ActiveDocument and get Word to make the actual changes in the document?

Yes.

>>* I am used to having everything in Normal.DOT and don’t worry about what-calls-what

Muy malo, amigo. You’ve got to get way from coding up Normal.dot. If you heed this one piece
of advice it’ll save you from many many miseries in the future. If you cannot put a global template
on LAN servers and set the Word Startup folder accordingly (due to IT constrainsts), then you
have no choice but to create COM Addins either via MOD or .Net. But the COM Addin choice is actually the best.

I’ve been doing this for a while and my conclusion is 1) VBA to learn the object models, OLE, API, etc.
2) COM Addins to create production apps.

>> It feels like COM Add-Ins written in .NET would be both.

Correct. You can write COM addins that make Word (or any Office app) talk to a .Net library, and
you can write COM Addins that make a .Net solution manipulate Office apps.

>>I hope these questions aren’t dumb.

p.s. These were some of the dumbest questions I have ever answered. NOT!

Reply | Quote