I wrote a program and uploaded it to www.download.com.  They copy-protected and configured my .exe file to "try & buy" with their Protexis technology, then they gave it back to me in a zip file with this readme.txt file:

    What's in this zip file?

    - YourProductName.dat: This is your original application, encrypted and renamed as a .dat file. For example, if your file was called YourProductName.exe, it is now encrypted and renamed YourProductName.dat.

    - YourProductName.exe: This is the license monitor and application launcher that replaces your application. It uses the same name and icons as your original application.

    - This readme.txt file.

    What do I do now?

    1. Rebuild your installer, including both the .dat and .exe files in the same directory (your application now consists of at least the two files YourProductName.exe and YourProductName.dat).


    How do I rebuild an installer, as they specified, with VB2005?

    Tuesday, February 07, 2006 11:12 PM

All replies

  • I second your question.  I haven't found anything yet.
    Monday, February 27, 2006 3:26 AM

    Yuck...VBE presents you with the problem because it's intended for hobbyists and beginners, not professionals.

    The professional products have deployment capabilities that are more sophisticated that the VBE oneclick.

    But you are still not out of luck if you want to do a little leg work.

    Get a copy of RAR or maybe even zip with the personal execulable option. These will allows you to make and excutable that will open up and put those files where you want them on the user's system. What you lose is the abilitiy to specify prerequisites such as the framework, so you are going to have to recommend to your users that they download the V2.0 framework prior to running your program.

    Monday, February 27, 2006 3:34 AM
  • I figured out how to get mine done.  I was trying to make something difficult out of something easy.  I didn't see before that the 2 files I got back from Protexis are meant to replace everything in my build directory.

    The .exe file and the .dat file appear to be all I need, assuming that the user does have the .net 2.0 framework. I do have to test it on a system that hasn't had a test version of my program run on it to make sure.

    It seems like using an installer program (windows installer, install-shield, wise, inno, etc.) is all you need to do after that.

    The framework is a bit sticky at 22MB (and I thought the old vb-runtimes were bad for extra file cargo), but it should be straightforward to check the system during install to see if the framework is present - offer to download + install, if necessary - then continue the installation - or bail out if the user doesn't want to download it.

    Monday, February 27, 2006 6:14 AM
  • "

    The framework is a bit sticky at 22MB (and I thought the old vb-runtimes were bad for extra file cargo), but it should be straightforward to check the system during install to see if the framework is present - offer to download + install, if necessary - then continue the installation - or bail out if the user doesn't want to download it."

    This is a normal function of one click deployment. If the framework is not present, the installation will automatically download the framwork. It's quite impressive the first time you see that occur.

    Monday, February 27, 2006 6:37 AM
  • "It's quite impressive the first time you see that occur"

    I agree.  One-Click looks very slick... when it comes to distributing the prerequisites.

    However, as a programming noob who has several years in supporting end users and their applications in the workplace, I don't get why the applications get installed in the user's profile. Or am I missing something big about VBE here?

    I still think in terms of "the applications go on the machine" and "the user data goes in their profile".  It blew me away to have to dig into my profile to find the silly hello world application I built with VBE.

    My gripe would have been that you would have lots of instances of the same application installed on the computer system - one for every user profile on the workstation that would need to use that program.  That would be ugly if it was a medium or large application, on a shared workstation. 

    To get the application installed on a per machine basis, it looks like one has to put together a secondary mechansim to make certain the framework is on the target system, pull the program files from the build, and repackage them with another tool. 

    Is there a way to replace your executable, after building, before publishing, that will keep the application from becoming corrupted? If so, then I would love to know it.  I will use Click Once and  won't complain about installing to user profiles for a while...

    ReneeC - You do good things for this forum! Keep up the good work!


    Monday, February 27, 2006 7:16 AM
  • Well thank you, OnError....

    I'm going to surrender to conjecture here and for the record, it's my conjecture.

    I've done several VB6 deployements and as many in VS2005 and I'm by no means a deployment expert. I consider the deployment headaches of the people who put the 3.54 gigabytes of Team Suite together. My goodness!

    Also consider the XP capability of being able to pack up your files and move to another system. This includes such things as mail. The special directories are an interesting maze, but they are designed for users to be self contained as far as their databases of all kinds are concerned. Given this design philosopy although it's really inconvenient, it makes perfect sense where Microsoft has One-click putting executables and data.

    Microsoft has created VBE as a product intended for hobbyist and non-professional users. I would believe that complex multi-user applications which would be tageted say for the program files, exceed the parameters of what VBE was designed for.

    I could make some guesses about things based upon my own personal experience. I didn't like 2002 and 2003. I ad one of them on my system and continued to use VB6. One day I idly downloaded VBE and instantly fell in love with the new IDE and it's capabilities. I may guess that this was the exact purpse of VBE. Let's put money as a motivation aside for a moment. There is a large cadre of people who didn't like 2003-2003 and who elected to stay with VB6 meaning continued production of unmanaged code in an aging format -one that inview of new operating systems, was increasingly difficult to maintain an support. Product have life cycles and VB6 was around for a really long time and it's approachs was being rapidly dated in terms of newer operating system products.

    Keep in mind that Microsoft always sold VB as a standalone product in parallael with Visual Studio. NOW Microsoft is giving the equivalent of that away and letting people download it. Inspite of that, I see comments from new VB6 users everyday. Colleges are still teaching VB6 - Goddess knkows why but they are. Giving VBE away in a way of solving a lot of the technical problems that VB6 presented to Microsoft. Also it will have the same effects that AT&T had in the seventies when they gave UNIX away to institutions. C became a standard language of the up and coming and of students in the 70s and eighties. Giving VBE away can't help but have the same effect because there are lots of 14 year olds out there writing code in VB.

    So I believe that what you're seeing is the confluence of several things. It's microsoft's solution to user transportability. VS2005 directories for users are in the special directories tree also. What has been done is well though out as inconvenient as seems.

    When I first began, with DOT NET, I wrote a massive toolbar project with emulated the functionality of the Office toolbar. Descriptors and even images of the buttons are storred in a serialized file with and the serialization was accomplished by storing the descriptors in a distionary and serializing the dictionary. The schema will work in any combination on a single user system. But suppose, I intended it to be multiuser in scope. I'd have have to really increase the complexity of that database to include user descriptors. Such a solution though discorages user transportability because of a common database. See what I mean? In order to support user transportability Microsoft absolutely had to do what they did. In older parlance, it's not a bug, it's a feature.

    As painful as it is.... Microsoft. since Windows 2K has been developing this concept in increasingly complex ways. Remembering way back when, even WIN95 had the rudiments in the Windows directory but it just was neither meaning or adequate for multi user machines.

    Has this resonated with anything. 

    Monday, February 27, 2006 8:59 AM
  • ReneeC, thanks for the reply.  Your "conjecture" is well thought out, and thank you for taking the time to post it.

    I realize that VBE is not meant for serious application development, and deployment, and that Microsoft is currently giving it away (which ends in November - then becomes $50 +/- to those that are interested), and that it is not designed to be all things to all people.

    I suppose that as a (wannabe) developer, I would need to step up to the plate, and become proficient in C/C++, or Assembly, to have the nearly complete control to do exactly what I think is right for each application.  I guess that also means that I would expect to have to shell out serious money for the appropriate tools to get that job done as efficiently as possible.

    This philosophy of trying to make the user applications and data as transportable as possible, seems, on the surface, to be a wonderful idea. But, in my experience, it rarely works as planned. Whenever you attempt to do this type of a data migration, what you usually end up with is bringing whatever problems, or issues, that were associated with the user's profile on the source computer, to the target computer. In our company, we looked at using the migration tools for our last computer upgrades, but we found that neither the built-in, nor downloadable, tools were as granular as we needed, so I ended up writing a VBScript to get the job done.

    In my enterprise experience, the reason to move someone to another computer is usually because the system they are using has issues that are not worth spending the time, or effort, to troubleshoot. This is a case where all you want is the user's specific data, and not the applications, to be migrated. I think this is the main driver for me thinking that applications do not belong in the user profile.

    The other issue I see with it is that installing applications to user profiles, means that if your company uses roaming profiles, you have to transfer a whole lot of unnecessary data and programs over the network, every time a user logs on to their system. (I don't know the facts, there may be a mechanism in place that only downloads and installs the application to each computer once, but I would be surprised.)

    Anyway, I really am in love with the VBE IDE so far, I'm sure its just going to be a learning curve for me to figure out whether it will be capable of doing what I want. I am looking at it as a stepping stone to determine whether to go with VB.Net, or just make the effort to wrap my head around C++ and go that route.

    VBE 2005 is absolutely cool, though. I intend to keep learning it.

    P.S. I have only written two applications, so far, that I would let anyone see, so I have a long way to go before I can reasonably expect to get out of NOOB status. One was in VB6, and the other VBE2005.

    Monday, February 27, 2006 3:03 PM

    Hi OnError,

    "I suppose that as a (wannabe) developer, I would need to step up to the plate, and become proficient in C/C++, or Assembly, to have the nearly complete control to do exactly what I think is right for each application.  I guess that also means that I would expect to have to shell out serious money for the appropriate tools to get that job done as efficiently as possible."

    I used to do drivers as a principal engineer or Digital and I did them in assembler. Yes, I've play with assembler for the Intel instruction and and actually I find the instruction to be an uber mess.

    Digital was the "un-C" company... and although I am a very adequate programmer, I'm not the least bit interested in the syntax, case-sensitivity and squiggles of the C derived languages. There have been discussion after discussion on the relative merits of C an VB and there are practically none.

    And it's also a bit like sexism. In society society, the "flaws" of women are made apparent against an implicit male standard. The "Flaws" of VB are constantly pointed out by C people and VB people are non-plussed by zealousness. But if I say, "Hey, the string handling capabilities are much better in VB, the response is, "No, it isn't.", only to note that the speaker has to turn himself inside out to do proficient string handling in C#. Performance is no better because they both run on the CLR. So no you don't have to do either C# or assembler to be a goo programmer. There are very specialized places where the unsafe code blocks of C# is useful in image processing.

    As a systems programmer, I have two copies of XP on my system. One is an emergency system that I boot when there is damage to the primary system. I ALWAYS live to regret formatting the main partition without saving my user tree. There are other enterpise reasons for that treee. Usually when an employee is moved the hardware stays in place and the users data goes with the employee which is why that kind of transportability is important.



    Monday, February 27, 2006 4:51 PM
  • http://msdn.microsoft.com/vstudio/express/visualc/default.aspx

    HiOnErrorGetHelp.... MS is also giving away C++ Express which writes in Native or .Net..... That along with C#E and J#E are a family of MODERN Languages which are very similar in Syntax etc... Why is VBE so Sacred???? It’s a Blast from the Past..... Why not Transist to Today???? Also for about $800 US You can get it all or most of it anyway..... Cheers

    Monday, February 27, 2006 8:59 PM