We have some old VB6 code that was apparently developed using something called the MMC Snap-In Designer. I'm having trouble finding the best path forward to restoring this project's functionality. For whatever reason it no longer works (I don't know why or when this happened). When MMC loads the MSC file, and the snap-in's node is selected, we just seen an error, "MMC could not create the snap-in." I personally don't even know what this snap-in is supposed to look like or do, so re-implementing it is going to be a challenge.
One path is to try to find the version of the platform SDK that I've heard tell contains this MMC Snap-In designer, download and install it, and see if looking at this project in the IDE gives any clues about how to make it work, or at least how it used to work. There's also the possibility of just identifying some missing registry entry that we may have somehow lost over time or as we transitioned to supporting a 64-bit OS (while most of our code still compiles to 32-bit binaries).
However, I would prefer to upgrade the VB6 project to something newer if there's any possibility of upgrading snap-in designer projects to whatever is being used today. I have no familiarity with this old Snap-In designer, but at least if we had some way of upgrading this code to something modern, I would be able to learn about snap-in development using currently available resources. Is there any upgrade path for these MMC Snap-In Designer projects?
Although I was not able to find an automated upgrade, I found that, at least in our case, manually rewriting the VB6 code for the MMC snap-in into VB.NET was relatively easy. This was partly due to the fact that the snap-in structure itself was quite simple, and partly due to the fact that all the functionality was in a separate DLL that was already VB.NET. I think the only helpful advice I have to pass along is that the VB6 code for the snap-in (even if you don't have the snap-in designer installed) can still be accessed via a text editor by loading the .DSR file and scrolling down a ways. I think the object model for implementing an MMC snap-in from .NET is rather different than the model used by the VB6 MMC snap-in designer, but the .NET model is pretty easy to deal with if you know what you need to accomplish. Just refer to the VB6 code in the DSR file for the pieces of code that aren't related to MMC, and use a higher level understanding of the design (not that code directly) to re-implement the purely MMC aspects of the project.
Related
I am supporting a vb6 application. I am trying to transfer the executable and DLL to a new server and I am prompted with component not registered errors. I have got round this by manually registering the components on the new server.
I have found two files with file extensions of 000 and 001 that have registry commands in them (registering components) Can anyone explain how these files are generated? I have experience creating installation files in vb.net to a certain extent.
Repackaging and redeployment is not a developer issue and really doesn't belong here. Such issues are more appropriate for someplace like ServerFault.
It is one thing to have lost all of the source code of an application, but even worse in some ways to have lost the deployment package. Sadly some shops fail to archive either of these.
However it was also common enough for shops to see RAD tools like VB6, Delphi, PowerBuilder, etc. as things to shove off on the worst of the worst of their developers. These poor slobs seldom got official Microsoft training that should have emphasized the importance of creating proper installers. For that matter even those courses tended to marginalize the topic. It doesn't help that the Web is full of "Mort teaching Mort" half-baked development even today, or that the pioneers who wrote many of the early serious VB programming books tended to be loose cannons and contrarians who didn't really believe deployment was a serious concern.
The end result is that lots of shops have machines with VB6 programs shoehorned onto them in a half-baked way. Often when deadlines loomed they let Old Mort install VB6 right onto the production server and let him hack away right there! So it's no wonder people get into trouble once a server needs to be replaced or its OS updated.
Those REG files with .000, .001, etc. extensions aren't anything normal that I'm aware of. For all I know they've fallen out of REGMON runs or some 3rd party packaging tool. Manual registry exports created using REGEDIT would normally have .REG extensions.
If you are actually "supporting" this application it implies that you have the source code, VB6 compiler, developer install packages for any 3rd party controls, and a writeup describing any special packaging and installation requirements (target machine DCOM/COM+ configuration, system requirements such as IIS or MSMQ or 3rd party DBMS Providers and Drivers, special folder requirements, software firewall rules, etc.).
From those it ought to be possible to compile a clean new copy of the EXE, DLLs, etc. and create a clean deployment package - even if some configuration still needs to be done manually before and after running the installer.
Without those you are a computer janitor and your question belongs over at ServerFault. It is no fun, I know. I've had to take part in such janitorial services myself all too often.
I have a serious issue, my harddisk crashed yesterday , and i had tons of projects on it .I lost most of them but the ones i recovered are all the debug folders i sent to clients (most of them are desktop applications). I am unable to recover the code for most of the work , but i do have debug folders , my question is is there any way that i can recover my code from them.
I am sure some one you would have gone through it in the past, please help if you have any information regarding this.
Files in the debug folder:Example i make application apple
apple.exe type=application
apple.pdb type=PDBFIle
apple.vshost type=Application
apple.vshost.exe.mainfest type=MANIFEST File
ADDITIONAL INFO:
My laptop hardisk crashed so i am currently using it as a usb drive with another laptop . I had 3 partitions but now i see 4 i,j,k,l . One of them which used to be my D: drive working fine, i see it shows 72 GB free out of 150 GB. Rest of them they are just there no info, when i click them nothing for minutes then it says format drive etc... If you know how to fix that that would be wonderful.
Thank you
You really lucked out with having access to the Debug folders containing your compiled binaries. The fact that you're working in a managed language (C#) means that you can use one of the many .NET decompilers to display the source code that they contain in a readable format. It may not be exactly the same as what you initially typed into Visual Studio, but it will be pretty darn close—way better than can normally be expected in the event of a system crash.
I used to recommend Redgate's .NET Reflector for this task, but they recently decided to eliminate the free version of their decompiler utility and adopted some business practices that I personally disagreed with. Then again, their tools are probably still the best around, so you might consider downloading their 30-day trial to attempt to get your code back. Who knows, you might like it so much that you buy!
If you're a cheapskate like me, or a devotee to truly free software, you can try one of the free alternatives that cropped up after Reflector became not free, like ILSpy, developed by the same people who develop SharpDevelop. Even more alternatives are listed here.
Whichever decompiler utility you choose, download a copy and open its executable. Then from the "File" menu, choose "Open", and navigate to the first compiled .exe from which you want to recover source. The utility will display the name of your application and some metadata about your assembly. From here, you can make sure that you opened the correct file.
In both ILSpy and .NET Reflector, you can click the [+] toggle next to your application's name to expand its listing. You'll see a bunch more expandable items, like References (the DLLs that your application uses), Resources (the resource files compiled into your application), and the namespaces defined in your code. Expanding an individual namespace will show you all of the types defined in that namespace, and expanding a type will show you all of the types, methods, members, etc. defined in that type, and so on down the hierarchy. Clicking on individual items in the source tree to the left will display the decompiled code in the output pane to the right; both ILSpy and .NET Reflector support displaying the code as C#, which should look very readable to you.
For example, using ILSpy to open the ILSpy.exe application itself produces the following output:
You really can't break anything in here, so navigate around, exploring and seeing what all can be recovered, amazed at how well this works. Everything works just as well with DLLs as it does with EXEs.
Then get started copying and pasting...
The next order of business is getting your system stable again. If you had a hard disk crash, you definitely don't want to trust that drive ever again! Run out and buy a new one immediately, wipe it, and reload Windows.
Once you finish with that, you definitely want to get on setting up a source/version/revision control system to use in the future to store your code. All smart developers use this for so many reasons. Find more information with a Google search. There are lots of different options. Which one you pick is not important; the important thing is that you pick one!
I've a need to analyze an .OCX in order to create a spoof -- the original installation files for this particular component are gone and the company that made it no longer in business. I can identify where it is used in the program that used to use it (and my understanding is that the feature the component made available never worked anyway).
Are there any tools (preferably free) that can do an analysis of .OCX's? The program that uses the component is written in VB6.
NB: As it happened, I mis-stated the problem a bit: I don't have the .OCX, and have to infer its interface from the VB6 project that uses it. And this is 100% Old School VB6. VB6's Object Browser isn't going to help me, and neither is any other OCX analysis tool, sorry. I have to analyze the VB6 project to determine how the OCX is being used, and a tool to do it for me would be what I'm looking for, here.
Microsoft's free OLE / COM Object Viewer tool (OleView.exe) may help you here. Launch the tool, and select "File -> View TypeLib...", then browse to your OCX.
You'll see all of the COM interfaces & coclasses inside the OCX.
I assume you're using Visual Studio .NET. You should be able to go to View->Object Browser. Click the ellipsis (...) and edit custom component set. Then go to the browse tab. Select .OCX in the Files of Type drop down. Then find your file.
VB6 also has an object browser.
I'm considering using the VB6 Common Controls Replacement Project controls and would like to see what other's experiences with them are.
Specifically:
What do you need to distribute with them? (I assume just the .OCX file)
Do I need to register the .ocx file or just include in the app directory?
Do these controls depend on any other ocx's? (There is mention, for example in the Progress Bar replacement that it is using COMCTL32.DLL but the .DEP file does not list that DLL.
Are they at least as robust as the controls they replace?
I've used various of the CCRP components in various projects (specifically BrowseDialog, FileDialogs, FolderTreeview and High-Performance Timer) and have had no problems with them. To answer your questions:
1) Just the OCX or dll is required to distribute them.
2) Yes they need to be registered.
3) The controls they depend on will be on every system (comctl32.dll is all of the common windows controls and no GDI app without it).
4) The ones I have used I have never had an incident with. I haven't used all of them, so I can't speak for all of them, but they were always very robust for me.
We have several apps that have used the CCRP FolderTreeview successfully for years. We have been seeing very hard to find crashes running on Widows 8, and believe we have isolated them to some strange interaction between the FolderTreeview and Windows Explorer instances open on the same folder.
If this is confirmed, it would suggest that you really don't want to use the CCRP FolderTreeview anymore.
As of this time, the CCRP project seems to have been dead for a long time (website copyright is 2004).
However there is a different, living, and apparently successful replacement project which may be useful:
http://www.vbforums.com/showthread.php?841929-VB6-ActiveX-CommonControls-%28Replacement-of-the-MS-common-controls%29&p=5129155#post5129155
I have used this in projects and it works well. Note that there are several variants of the VBCCR library including an OCX as well as code which is meant to be compiled into your own program.
1-3) The DLLs are presumed to be on every system -- you distribute (and register) the OCX only.
4) What controls do they replace?
We've got a desktop product, made up of a Win32 service, a notification icon application and associated DLL files.
I've been tasked to look at making it auto-update. We could write our own updater, but before we do that, I'd like to see what else is out there. Are there any commercial systems (similar to Windows Update, I guess) that we could use? I'm sure that InstallShield used to offer something like this, but I can't find it now, and it's possible that my memory's failing me.
It's a Win32 application (and a service), so ClickOnce is out (or is it?).
Have a look at Google's Omaha project.
I once looked into using it. But I eventually realized it would be easier to re-invent the wheel than to learn everything that goes into making Omaha work. Unfortunately I have yet to find a generic solution. Most project's I've looked into tend to build their own updater.
Which is bad, because everyone tends to make the same mistakes over and over again. Doing secure updates isn't trivial. Read this:
Auto update: Is this secure?
I also find it rather annoying how every auto updater thinks it needs to be running 24/7 in my system notification area.
I would venture to say that one of the main advantages of of the app store model is that developers don't have to worry about building an update system.
I highly recommend GUP: https://wingup.org/
It's the automatic updater developed by Notepad++ author and it's completely opensource.
You might want to use this solution. Source code (c++) included.