If you are wanting to play with VSTO and want a simple, easy to carry intro, this isn’t it. It’s massive and it weighs a ton!
But that is because it covers all the main Office apps, well Excel, Word and PowerPoint, I dunno what the Access/VSTO story is. Maybe the Access boss was out the day they decided to point VS at Office?
This is a good book. I’m always a little sceptical on books, especially if I don’t know if the authors are commercial devs. I know the two Erics are key members of the VSTO team, but thats not the same as delivering and supporting, using the book contents, to paying clients. With this book though you can just follow through the examples and deliver working solutions, that actually work.
My only issue is with the section on UDFs using Automation add-ins – c’mon guys, everyone knows .net automation add-ins are completely inadequate for commercial use. Sure show the tech, but at least warn people that the performance is pitiful. Otherwise someone will use just that section, see how crap they are and assume that the rest of the book and the technology is as bad, and it isn’t.
The rest of the book (I didn’t bother with the non Excel stuff of course) looks like a simplified version of what to do, but actually VSTO 2008 is that simple. All that Caspol security bobbins is gone and getting your VSTO solution working on someone elses pc is now really straightforward.
The book is just C#, but you can download the VB stuff from their site. But I would strongly advise anyone wanting to look at .net to seriously consider the move the C#, sure there is a bit of a learning curve, but the resources are so much richer, and the language is so clean (well was – its getting more cluttered all the time). If you just want to get things done, stick with VBA, if you want to develop and grow as a developer take the plunge and try C#. Of course dropping back to VBA and putting a ; at the end of every line is a pain…
I’m not completely convinced by VSTO, I think the VS2010 v Office 2010 story will be pretty slick, but the VS2008 stuff v Excel 2007 is really quite flaky. I think in 2010 they have actually fixed some things they just patched in 2008 (I’m thinking the locale ID mess for one thing).
My preference for Excel add-ins is still xlls and with the rapid rate of improvement and availability of tools in this space, its getting better and better.
I have a click-once server deployed VSTO add-in live at the moment and its pretty neat. I publish new version any time I make a change and the users get it the next time they start Excel, easy squeezy. Moving it from the test server to production was a pain, but once live, updates are very smooth. Then again we have an add-in loader which does the same thing for .xlas, .xlls and .xlams so maybe its not that great a leap forward…
Anyway if you are doing VSTO development this is the book to get. PED also has a good section on Excel/.net covering all the options as well as going into detail on VSTO with VB.net.
How are your VSTO projects coming along?
cheers
Simon
Smurf on Spreadsheets 
Sunday, 2nd May, 2010 at 11:19 pm |
Absolutely agree with “if you are doing VSTO development this is the book to get” – this is IMO the missing VSTO user manual. The book is a brick, and just because it looked so intimidating, I postponed reading it, but once I started, I found it actually very well written, and if you already know your way around VBA and the Excel object model, this is a great way to get started with VSTO.
I haven’t played with ClickOnce yet, in part because I hear that without a certificate, it’s not worth it. Any comment on that?
Monday, 3rd May, 2010 at 10:15 am |
Mathias good points, it is easy to read and follow, and the General + Excel stuff is prob 1/4 or 1/3 so we shouldn’t be put off by the size.
We are deploying within the firewall, but its not signed, users just get an ‘untrusted’ prompt on first install (which we scripted away anyway). It just pops an informational dialog for updates that clears itself after a few seconds.
Monday, 3rd May, 2010 at 3:49 pm |
Simon,
My review:
http://xldennis.wordpress.com/2010/01/21/visual-studio-tools-for-office-2007-review/
This books is about what we can do and not what we should do. The VSTO section in PED tries to target what we should do. In my experience VSTO is driven by customer’s requests and it’s aiming at .NET developers at large corporates.
Kind regards,
Dennis
Monday, 3rd May, 2010 at 3:55 pm |
Mathias,
I always sign my VSTO solutions as it¨s make life easier for the end users. For me it means that I don’t need to tell the end users about security dialogs.
Kind regards,
Dennis
Tuesday, 4th May, 2010 at 8:14 am |
@Simon: does it require the user to have administrator privileges to install without a certificate? I think I’ll get one anyways, for the reason Dennis mentions, once I play a bit with ClickOnce; if it’s really easier that the msi installer, it sounds appealing, because that part is definitely not where the fun is for VSTO project!
Tuesday, 4th May, 2010 at 10:33 am |
I think Comodo certs are one of the best value these days.
If you have a pure VSTO project (and are not trying to squeeze in an .xlt or .xll or anything) then click once is mega easy
security/deployment:
http://msdn.microsoft.com/en-us/library/bb821233.aspx
We are scripting using SYSTEM and writing the registry key directly so I’m not sure, I think it did work with basic user rights from the test server link. (but the reg writing doesn’t)
Thanks for your link Dennis – I had meant to put that in my post. I was just getting ready to post this a few months ago when I saw you had just published yours so I held back. I have a PED review half done too.
Tuesday, 4th May, 2010 at 1:32 pm |
Hi again,
Yes, COMODO’s certificate is OK although it has become more expensive than earlier. If my memory don’t trick me CodeProject has a certificate that is rather cheap to buy. I don’t recall the details so it may or may be a web certificate only but worth to check out.
Simon, it’s more than one time that I have decided to drop a blog entry because You have covered the subject so well. The last was about XLLs ;)
I wish it would be possible to one day write a VSTO book that only target Excel. But I guess it’s not economical feasible…
Kind regards,
Dennis
Wednesday, 5th May, 2010 at 2:24 pm |
Simon:
Glad to see you guys are plugging away on VSTO. This is a good thing for Excel and Office development in general.
But I think we all have to keep things in perspective and understand that VSTO is specifically targeted at VS developers for integration into their VS solutions. I still think that the availability of a “macro” capability “inside” an Excel workbook is important. I also think that VS developers will never really have any interest in Excel as a dev platform or even an interest in “Good” spreadsheet development using the capabilities of Excel in an optimal way.
I will probably always think that really capable development of “automated” spreadsheets can only come from Excel “developers” up rather than by VS developers down.. :-).
In that context, if they replace VBA with some kind of internal .Net solution I’d be ok. On the other hand If they went the true “Macro” route (like in Access Web solutions in 2010), I would actually be VERY happy. I have never heard anybody mention that as a solution so there is no NDA issue there -just pure speculation on my part, but that would be ok with me.
Good stuff though guys.
Biggus
Wednesday, 5th May, 2010 at 3:56 pm |
Access macros may be fine for Access because Access can’t do as many things as Excel. That’s a good thing: Access, being a RDBMS, should be more restrictive. I have my doubts a similar macro facility would handle enough of the things Excel does to make it a reasonable replacement for VBA.
A fine example from where I work: I support a model which needs to pull in data from files stored in read-only folders which have .CSV extensions. Some of the fields in these CSV files contain subcomponents which need to be parsed into separate fields in the model. There isn’t a chance in Hell the department which produces the CSV files would reformat them with these subcomponents in separate fields. So the process the model uses is load the CSV file, insert columns, then parse the composite fields into the separate component fields. Would an Excel macro facility reasonably support this in full?
Wednesday, 5th May, 2010 at 4:09 pm |
Hi Harlan:
Yeah there are definitely things that you can do with VBA that are pretty impressive. On the other hand I have found Access’s new macros are VERY capable and I would hope that all functionality in Excel could be emulated in Macros.
The unfortunate fact is that if we are ever to get to automate a version of Excel on the Web (using SharePoint os course :-) ) it will not be able to use VBA for sure and I wouldn’t be surprised if the only way to provide an internal “macro” capability would be to go to a true sandboxed nion-COM and non.NET macro capability.
If you need more (like you described) then you would possibly need VSTO at least in early versions. Sucks but probably true…
The question has to be asked “Does Office automation have a future integrated with other “Development languages and tools or will it end up a localized isolated capability – a true “Automation Macro” As an Excel developer first and foremost I can see the value of that – but it sure doesn’t sound cool does it?
Part of the problem with Excel developers being the “Red-Headed Step-Children” of the dev community. Again I say what I’ve always said that Office development has to drive outward from the documents within the environment. Automation should be just that – automation…
Dick
Dick
Wednesday, 5th May, 2010 at 5:44 pm
I’m in a foul mood about Excel Services at the moment.
Just as Office 2010 is about to be released, the company where I work will later this year boldly roll out Office 2007. One model currently in use in Excel 2003 uses a macro which calls an external executable to perform some simulation calculations. Classic program: roughly 300 lines of code with a few dozen loops performing a few million nontrivial floating point calculations. It has a RAM footprint less than 512KB. IT can’t/won’t abide this for Excel 2007, so they want to handle this using Excel Services.
The Excel workbook equivalent requires several hundred thousand cell formulas and weighs in at over 4MB, and it’s that small because the final step uses a what-if table to evaluate 5000 or so formulas for 200 varying single inputs. Brings out the curmudgeon in me: YES, there are cases where 40-year-old programming approaches do work better than the latest fad.
[BTW: are there any problems using what-if tables, so the TABLE pseudofunction, under Excel Services? There’s squat all on this using either Google web or groups searches.]
[Tangent: this almost isn’t possible in Excel because of its 15 decimal digit limitation. Intermediate values seem to be held in the 80-bit FPU register stack in the executable, but they need to be stored as 64-bit doubles in Excel worksheet cells. Had to get inventive to work around this. There are times Excel really sucks compared to alternatives.]
Wednesday, 5th May, 2010 at 4:24 pm |
Hi D,
>>Glad to see you guys are plugging away on VSTO.
I started out with version 1.0 and with version 4.0 we get a really good tool :-)
>>I also think that VS developers will never really have any interest in
>> Excel as a dev platform
Nopp, in the same way as You just want a VB.NET solution to work without any regards to best practices.
However, VS Developers contribute with some good points, especially the lack of events for some major objects in Excel’s object model. Personally I welcome it :)
MSFT recently announced that they will from now accept a coevolution of VB and C# which is very good. The same idea can actually be applied with VBA and the new platform that will come with Excel 15. In that way all the VBA developers will be happy as well those of us who is looking forward to a new development platform inside Excel ;)
Kind regards,
Dennis
Wednesday, 5th May, 2010 at 4:56 pm |
” The same idea can actually be applied with VBA and the new platform that will come with Excel 15. In that way all the VBA developers will be happy as well those of us who is looking forward to a new development platform inside Excel ;)”
I’m not totally sure what yu mean there …. can you explain a bit more what you mean by that?
Thanx
Dick
Thursday, 6th May, 2010 at 9:50 am |
Dick,
At present MSFT works with building up a online VBA section at MSDN (where some of my articles will be published). This indicates that MSFT have an interest in VBA, at least to me.
When MSFT say that they will let VB and C# be equally developed side by side it’s a paradigm shift. In other words, they will put the same efforts to develop these two languages. Personally I see it as an advantage as these two languages compliment each other.
Ever since we became aware of that a new modern development platform will be implemented in Excel we say that “VBA will be replaced by…”.
Today we know that VBA has some shortcomings (compared with VSTO) and that VSTO also has some shortcomings (compared with VBA).
Instead of thinking that VBA will be replaced why not think that VBA and the new xxx will coexist in Excel and will be equally developed like VB and C#.
For me it would be the perfect scenario for everyone and VBA will also be recognized by MSFT as a development platform!
I hope the above better explain better what I like to say. If not I will write in Swedish and You can use Bing to translate it ;-)
Kind regards,
Dennis
Thursday, 6th May, 2010 at 12:38 pm |
“Instead of thinking that VBA will be replaced why not think that VBA and the new xxx will coexist in Excel and will be equally developed like VB and C#. ”
That’d be great … I’m just not so sure it’s gonna happen … To quote the great philosopher Mick “You can’t always get what yo wa-ant…”
Dick
Thursday, 6th May, 2010 at 3:18 pm |
“Instead of thinking that VBA will be replaced why not think that VBA and the new xxx will coexist in Excel and will be equally developed like VB and C#.”
Sounds like a good plan, but I’m not sure it’s one that will be followed. Given the rapid replacement of XLM by VBA, though, we will all be retired before VBA is gone.
Thursday, 6th May, 2010 at 11:08 am |
“Ever since we became aware of that a new modern development platform will be implemented in Excel”
This is news…Are you suggesting that MS plans to introduce a new programming language that will co-exists with VBA
Thursday, 6th May, 2010 at 1:21 pm |
Dick,
Perhaps it’s a Highway to Hell but it’s better than to be served a Goats Head Soup to dinner.
sam,
Why not? XLM was not removed when VBA was introduced and to some degree XLM also works with Excel 2010.
Kind regards,
Dennis
Saturday, 8th May, 2010 at 4:20 pm |
gents,
isn’t the obvious language to learrn DAX?
just seems like for excel solutions that this is the most important thing to learn now.
-greg
Monday, 10th May, 2010 at 7:24 am |
thats funny Greg!
(dax:
http://msdn.microsoft.com/en-us/library/ee634556(v=SQL.105).aspx)