Al Christoph

I have a rather convoluted project. The distributable will come in eight different flavors, each with its main program, libraries, datafiles, doco, etc.

Each flavor will also have one or more standalone executables that can be called as tools from within the main program.

To complicate matters I'm using VSS 2005 to track everyting and I'm trying to use links both within the IDE and VSS to minimize the possibility of error and to let the IDE do all the work at build time. This works great with the datafiles, doco, etc. (Though I wish that it were possible to use the content / copy mechanism to copy to directories parallel or even below bin rather than within bin. It's nice to have the readme file in the root. Anyone at MS listening BTW if I've overlooked something that would allow this please let me know.)

QUESTION: Without building a setup / deployment project, i.e. with just relying on the IDE's main build / package mechanism, how do I specify that the tools need to be included in the distribution

I tried linking them and the build barfed. I used add existing item to link to the tool's exe and config file if any, I put the link in a tools folder with the hope that it would work just like the data and doco and artwork which is working splendly thankyou. But the build doesn't allow that.

So what should I do A separate setup project is out of the question!!! I've promised installationless operation as a key selling point. And that of course is no problem with framework. The program needs to play from a cd-rom without installation.



Re: Visual Basic IDE Deploying multiple EXE's using the basic publish mechanism of the IDE

Spidermans_DarkSide

Hi,

What is the difference between the 8 flavours of your program

Can you not put an OPTION menu item in your project to switch between them

as if they were one HUGE project, say on 8 separate forms if that is the only way to do it

 

 

Regards,

S_DS

 






Re: Visual Basic IDE Deploying multiple EXE's using the basic publish mechanism of the IDE

Al Christoph

Interesting suggestion. For all intents that is exactly how the main exe works. Everyone gets the same code base (except for the icon resource which must be different and therefore must be in the exe so that it shows up correctly on the start menu, desktop, etc. There is no setup program so such things have to happen automagically.

The problem is that the 8 flavors go out to 3 different companies to distribute to their customers. Two of these companies operate different subsidiaries using different flavors. The fiction is that the customer doesn't know this:-) It is all the auxiliary files that have brand information in them that mean I can not have a single complete package. For example the release notes contain the appropriate corporate logo. (Giving everyone everything would allow the customer to see the wizard behind the curtain.) Plus one of the flavors has lots of tools that none of the other ones have and their distribution is a security issue.

So the bottom line is that MS screwed up and really has no fix that is completely satisfactory supposedly until Orcas comes out. When I get the Orcas beta bits up I'll try this and report back.

I've been living with this mess for 6 years now. (VB6 had lots of conditional compiles, a setup program, and my own ingenious build process that kept everyting separate.) When MS gets it right, it will be a very good thing.

Regards,

Al





Re: Visual Basic IDE Deploying multiple EXE's using the basic publish mechanism of the IDE

Spidermans_DarkSide

Hi,

Here are another 3 ideas then.

Have the program ask the very end user once to register the product with

 companyName,  emailAddress only.

Write a registration file to the hard-drive somewhere as a hidden file including a backup copy of the file.

 You could have the registration process to email you these details.

 Now for the clever bit.>>

The program looks for this file in the Form_Load event and if the file exists then the program runs else it checks for the backup copy and only then will it ask for registration details again.

 Now i guess you can customise your program-solution based on this info

Or    just use the numbers 1 through to 8 in a text file written to the client's p.c.

 The end user won't miss loosing just a few bytes to a file if you write the character "1" to a textFile.

You could call these files reg1.txt and reg1.bak and then hide the files.

Carry on up to reg8.txt with reg8.bak.

Then distribute your eight versions this way maybe

Or 

Personally i would copy the project-solution folder 7 more times so you end up with 8 solutions or as many as your client needs, just customise each one.

 

Regards,

S_DS

 






Re: Visual Basic IDE Deploying multiple EXE's using the basic publish mechanism of the IDE

Al Christoph

Great ideas. In fact the program does your first (getting company name, etc) as a part of its first run i.e. what is normally the function of a setup program is handled by the program itself. The data is stored hidden, zipped, and encrypted. The user is bugged for it every run until he gives.

However you miss the point, perhaps because I have not made myself clear. Here is the situation using fake corporate sponsors and products.

Flavor Sponsor Facilities Sponsor Product Types

1 A All Sheep and Goats
2 A Basic Sheep and Goats
3 A Basic + Sheep and Goats
4 A Basic + + Sheep and Goats
5 A as B Basic Sheep and Goats
6 C Basic Goats only
7 D Basic Sheep only
8
D as E Basic Sheep only

As you can see Sponsor A maintains the fiction that B is not A and sponsor D maintains the fiction that E is not D.

The Sponsor is not the primarily user of the flavor. He distributes it to his customers and they use it. Thus, Farmer Brown might have Flavors 2, 5, 6,7, and 8 on his PC all in separate places with separate Read Me and Credit Files and a few other things that differ from flavor to flavor. When Farmer Brown first opens the program he puts in Farmer Brown Enterprises as his company name, not the flavor he is using. (How would he know what the flavors are We sure are NOT going to tell him.)

The program installs either via ClickOnce (when MS gets it working) or via the classic XCOPY to the desktop (drag from CD-ROM.) In the later case all the files are exposed.

In your scenario the enterprising user need open the single folder to expose all the different readme's with the brand logo's and the fiction would go away.

The facilities are a major gotcha. The distinctions come two ways. "All" implies everything the main program can do plus 8 tools. Basic implies just one functionality in the main program and one tool. Basic + adds a functionality to Basic. Basic ++ adds two functionalities to Basic. The control of what the main program can do (remember all the executable bits are the same) is provided in an external encrypted xml file. The program name is used as the lookup in that file. Program names are embedded in the bits and thus are not subject to user changing them. Thus, if you get flavor 7 you've got all the bits to do everything (though not all the tools) but because it's flavor 7 you only get Basic functions for Sheep.

So just as a reminder - the basic problem is two fold

1) The tools are separate programs - some of them are needed to boot strap the whole process. Including them properly in the build and turning on ClickOnce crashes the build process.

2) The support files are branded. Hence the need for separate processes.

Regards,

Al





Re: Visual Basic IDE Deploying multiple EXE's using the basic publish mechanism of the IDE

Spidermans_DarkSide

Hi,

As you are using encryption then on your XML files,

then why not use the same technique on your support files and only make them readable from the HELP menu of your program-solution

If a user tries to browse the cd for documentation all they will see is garbage.

Encrypt then ALL of the bits that you don't wish each end user to see without the program being run.

Regards,

S_DS