MSDN OS Subscription, or not?

[howardkaikow]

I use VB 6 Enterprise to do stand alone programming, and, more importantly, to create .exe and .dll that use Excel, or some other Office component.

Since the proper way to install Office is to only have a single Office in each installed OS, it can get rather expensive getting a license for each OS.

Each Office can be installed on both a destop and a notebook, so if the desktop and notebook use a different OS that helps.

Last week, I had a lengthy discussion with folkes in the MSDN Subscription group. They indicated that getting an MSDN OS Subscription would enable me to install as many OS as I wished.

Sounded good, too good!

But yesterday, I learned that there are severe restrictions on how each OS can be used.

My goal is to develop in my main OS, right now Windows 2000 with Office 2003, and Windows Vista with Office 2007. Then boot to the systems that have Office 97, Office 2000 and Office XP for testing/tweaking the VB 6 code.

I will be building a desktop to use Windows XP (I purchased a retail version before MSFT stopped sales). I would also like to add, perhaps, additional Win XP to the desktop, and, Vista and Windows 7. I may eventually add Windows 7 to the Vista notebook.

What's the most cost effective way to get the needed Windows licenses?

[dclamp]

1. You can ask your friends if they have copies of the OS that you need.
   
2. If you're a High School or University Student, you can sign up for a DreamSpark account, which gives you a Server 2003 and Server 2008 free of charge.
   
3. Sign up for MSDN, however MSDN subscriptions have a large price tag
   
4. Buy licenses for them.

I would say 1 is the most cost effective.

[RhinoBull]

I would try using MS Office dev edition - I believe it allows distributing runtime components so your users wouldn't need to deploy entire product.
Another option that I would consider is to research on some third party grid control (Gridex2000 and TrueDbGrid come to mind first) that has "export to excel" functionality.
If your budget is tight second option may save you some money - the only problem with this is I'm not sure if excel is required to be installed on the destination machine.

[Hack]

I would say 1 is the most cost effective.

It is also illegal, unsupported and is never used by legitimate professionals.

[howardkaikow]

I would try using MS Office dev edition - I believe it allows distributing runtime components so your users wouldn't need to deploy entire product.

There has not been an office dev edition since office XP.
In any case, only Access has distributible run times.

Also, I am not concerned with distribution, rather with:

1. Testing with each version of Excel.
2. If necessary debugging using VBA source, which requires more than just runtimes.

Another option that I would consider is to research on some third party grid control (Gridex2000 and TrueDbGrid come to mind first) that has "export to excel" functionality.

Has to be Excel.

If your budget is tight second option may save you some money - the only problem with this is I'm not sure if excel is required to be installed on the destination machine.

Excel will be required as there are no distributables for Excel.

[RhinoBull]

Excel will be required as there are no distributables for Excel.

I don't think you undestood me - if you use third party grid control chances that office runtime files are included are very high.
I would be surprised if ocx vendor didn't use dev edition of ms office when component was developed.
Having said that, when you distribute your application all legitimate functionality will be included (excel, word, etc).
However, since component will use original library your users may need to convert to whatever version they might have (if necessary of course).

[howardkaikow]

I don't think you undestood me - if you use third party grid control chances that office runtime files are included are very high.
I would be surprised if ocx vendor didn't use dev edition of ms office when component was developed.
Having said that, when you distribute your application all legitimate functionality will be included (excel, word, etc).
However, since component will use original library your users may need to convert to whatever version they might have (if necessary of course).

Excel has to be installed on the target computer, no way around that.
A lot more is involved than would be provided by a grid control.

[RhinoBull]

But you can at least be certain your program can deliver what they need - rest is up to your clients.

Anyway, it was only a suggestion.
Good luck with your project.

[howardkaikow]

But you can at least be certain your program can deliver what they need - rest is up to your clients.

Grid control does not provide the functionality of Excel.

[RhinoBull]

Oh yes, they do - not cheap though...

Formula One is arguably best.
SpreadsheetGear is another one but not sure if it's available for VB6.

There are some others...

[howardkaikow]

Oh yes, they do - not cheap though...

Formula One is arguably best.
SpreadsheetGear is another one but not sure if it's available for VB6.

There are some others...

Not appropriate.

My app requires Excel.

[dclamp]

Not appropriate.

My app requires Excel.

You are pretty much eliminating your option of being cost effective.

You asked us how, we gave you multiple solutions, and you rejected them.

I dont think you understand what RhinoBull is saying. Those 3rd party controls allow you to not have to worry about Excel. They have the same funtionablitly as excel, without it, saving you and your client money.

[howardkaikow]

You are pretty much eliminating your option of being cost effective.

You asked us how, we gave you multiple solutions, and you rejected them.

I dont think you understand what RhinoBull is saying. Those 3rd party controls allow you to not have to worry about Excel. They have the same funtionablitly as excel, without it, saving you and your client money.

I do understand the suggestions, but they do not work for the app.

The app is targeted towards folkes already having Excel, so using a 3rd party spreadsheet control is not appropriate for what I am doing.

Indeed, I am not about to rely on a 3rd party to supply particular Excel functionality. No reason to do so.