Assuming self-registration is used to install components as part of a larger installer program, why is self-registration bad? E.g. self-registering vb custom controls or capicom or whatever. I acknowledge that self-registration is probably not as safe in the case of a dll you wrote yourself, but I'm not discussing those.
The MSDN lists several reasons why self-registration is bad, reproduced here:
Rollback won't work properly.
OK, this reason makes sense.
Advertisement will not work as well.
Ignoring the fact that advertisement is only important for certain types of software clients, I don't understand why this is an issue. Only the main application needs to be advertised, not its components.
Self-registration does not support per-user keys properly.
So what? Giving every user access to "common" components is not a bad thing unless you have a lot of users on the machine, in which case it's still not world-ending.
Self-registration is more susceptible to coding errors.
I can definitely believe this, except in the case of dlls which were written by Microsoft (they may have errors, but I don't think trusting them is unreasonable). And in the case of tlbs and ocxs which were generated by software, coding errors seem pretty unlikely.
Self-registering dlls may link to other dlls.
In the case of dlls generated by programs, it doesn't seem likely that self-registration will fail due to this but adding the registration keys manually would have worked. I'd rather have my self-registration return an error that I'm missing the dlls.
I'm sure this will draw flames :/
Edit: Crossed out arguments that I think actually matter (based on user responses and my own).
As far as this item:
Self-registration does not support per-user keys properly.
So what? Giving every user access
to "common" components is not a bad
thing unless you have a lot of users
on the machine, in which case it's
still not world-ending.
It's not just a matter of how many users are on a machine, but also what permissions they have. If not an administrator, the user will be unlikely to have permission to update the HKEY_LOCAL_MACHINE portion of the registry.
The item
Self-registering dlls may link to
other dlls
applies when you try to register the dll, but the installer has not yet copied/installed another dll your registering function requires.
I would add one potential "gotcha" which I have run into (with auto-generated self-registration code for MS COM objects):
Self-registration runs the executable, with all that entails/requires. So, for example, if your component directly or indirectly logs the fact that it was activated (perhaps for security logging if the component is only supposed to be running at very specific points or in very specific contexts, or in coordination with other applications), registration will appear to be an activation (unless you're careful about logging). This can also be interesting if your logs record, say, the context in which the component was utilized, in which case you will have whatever inherited context triggered the self-registration.
Not a big deal in most cases, but it can cause some subtle confusion sometimes. I'd add it to the list of reasons why it's probably not preferable.
Related
I'm trying to update a software system to JDK-11 using modules, and everything was going just fine right up until I slammed head-on into the aforementioned issue.
I have a legacy signed JAR that I need to incorporate for interaction with legacy systems. There's no way to update the JAR and no way to get a new version. The JAR must be signed in order to be usable (the whole "trusted code" deal and whatnot). The problem is that the JAR contains classes in the unnamed (root) package. Yeah. Stupid. Bad practice. Blablabla. It's still there, and I still need to use it.
I've not found any documentation or answers anywhere that would remotely suggest that what I need is possible. In fact, the opposite is true: everyone is adamant that in the "new"(ish) module system, no class may reside in the unnamed package.
Needless to say I'm unable to both modify the contents of the JAR, or get at the sources to render a new one - that's without even considering the issue of the signature...
That said: I refuse to believe the folks at Oracle would leave such a glaring oversight with regards to legacy code. As we all know, a lot of the time we have no choice but to use it for legitimate reasons, and we can't do anything to fix/update/refactor/etc... I would have hoped there was a mechanism added to the module system to support this, albeit for extreme cases only, etc...etc...
Disclaimer: I do fully understand why this isn't meant to be supported. What I'm having a hard time with is the lack of a workaround...
Thanks!
I've already tried:
creating a facade module that transitively adds the offending module (obviously no dice, same problem)
unpacking-and-repacking the module while temporarily disabling signature validation in a test env (fails because the class is apparently referenced within many other, properly-organized classes)
finding an updated module (no luck here, either)
beheading a chicken and roasting it over a pentagram while invoking the aid of ancient pagan gods (tasty, but didn't fix it)
curling up in a ball under my desk and weeping until execution succeeds (that's where I'm typing this from)...
This is my first attempt to use the registry in any depth, so bear with me...
I write small VB.net programs that interact with Excel and other programs to produce complex reports. As part of this we sometimes have to interact with a 3rd party DLL. Since this DLL is generally very rare, we took an "always install" policy, and run their installer on first-start.
Well now we have a customer who already has the 3rd party app, so the install fails (as it should). But this leaves me trying to find where the DLL/app has been installed so I can call it properly. Poking about in regedit (causing it to repeatedly crash) I have found it seems to be like this...
Installing the DLL produces an entry called APLW.WSEngine in HKEY_CLASSES_ROOT, as well as an apparently identical copy in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\. Those entries both contain a CLSID which can be found in HKEY_CLASSES_ROOT\Interface\[the key]\TypeLib as well as entries for a variety of sub-parts of the install. I also find it at HKEY_CLASSES_ROOT\TypeLib\[the key], and here it has a key called \3.0\HELPDIR\ that contains the directory I'm looking for.
So...
What is the minimum number of calls I need to make to find the value in that HELPDIR key, or get Nothing or "" if any of the keys doesn't exist. In the end I either need that path, or nothing if the software has not been installed. Currently I'm making repeated calls into the reg to look up each entry and key in turn, but I suspect there is a way to chain them?
To make things slightly more complex, that \3.0\ in the path may change, the actual value is in the Version key in the original CLSID entry. If there is an easy way to add this I'll use it, but since we only work with 3.0 (AFAIK) it can be ignored.
Maybe 1. Maybe more. Don't know, this was not a very typically laid out question (which is probably why you got down voted), but I'm going to assume that you are more of a numbers / reporting person than a software engineer. So proceeding with that assumption, I will try and be helpful instead of pointing out any breaches of etiquette and provide you a couple resources that may help.
For starters, how to read a registry value:
https://msdn.microsoft.com/en-us/library/xz88758e.aspx
Secondly, the full tech spec on the Registry class in vb.net:
https://msdn.microsoft.com/en-us/library/microsoft.win32.registry(v=vs.110).aspx
Both give plenty of samples that should aid you along your way. But keep in mind that in certain situations and certain computer setups, these sorts of registry calls might require you to elevate your UAC permissions, if you run into such a case, you can try this resource, which covers in some detail how to make your applications UAC aware:
http://www.codeproject.com/Articles/17968/Making-Your-Application-UAC-Aware
I hope this helps, and good luck!
My firm's Access database has been having some serious problems recently. The errors we're getting seem like they indicate corruption -- here are the most common:
Error accessing file. Network connection may have been lost.
There was an error compiling this function.
No error, Access just crashes completely.
I've noticed that these errors only happen with a compiled database. If I decompile it, it works fine. If I take an uncompiled database and compile it, it works fine -- until the next time I try to open it. It appears that compiling the database into a .ACCDE file solves the problem, which is what I've been doing, but one person has reported that the issue returned for her, which has me very nervous.
I've tried exporting all of the objects in the database to text, starting with a brand new database, and importing them all again, but that doesn't solve the problem. Once I import all of the objects into the clean database, the problem comes back.
One last point that seems be related, but I don't understand how. The problem started right around the time that I added some class modules to the database. These class modules use the VBA Implements keyword, in an effort to clean up my code by introducing some polymorphism. I don't know why this would cause the problem, but the timing seems to indicate a relationship.
I've been searching for an explanation, but haven't found one yet. Does anyone have any suggestions?
EDIT: The database includes a few references in addition to the standard ones:
Microsoft ActiveX Data Objects 2.8
Microsoft Office 12.0
Microsoft Scripting Runtime
Microsoft VBScript Regular Expressions 5.5
Some of the things I do and use when debugging Access:
Test my app in a number of VM. You can use HyperV on Win8, VMWare or VirtualBox to set up various controlled test environments, like testing on WinXP, Win7, Win8, 32bit or 64 bits, just anything that matches the range of OS and bitness of your users.
I use vbWatchDog, a clever utility that only adds a few classes to your application (no external dependency) and allows you to trap errors at high level, and show you exactly where they happen. This is invaluable to catch and record strange errors, especially in the field.
If the issue appears isolated to one or a few users only, I would try to find out what is special about their config. If nothing seems out of place, I would completely unsintall all Office component and re-install it after scrubbing the registry for dangling keys and removing all traces of folders from the old install.
If your users do not need a complete version of Access, just use the free Access Runtime on their machine.
Make sure that you are using consistent versions of Access throughout: if you are using Access 2007, make sure your dev machine is also using that version and that all other users are also only using that version and that no components from Access 2010/2013 are present.
Try to ascertain if the crash is always happening around the same user-actions. I use a simple log file that I write to when a debugging flag is set. The log file is a simple text file that I open/write to/close everytime I log something (I don't keep it open to make sure the data is flushed to the file, otherwise when Access crashes, you may only have old data in the log file as the new one may still be in the buffer). Things I log are, for instance, sensitive function entry/exit, SQL queries that I execute from code, form open/close, etc.
As a generality, make sure your app compiles without issue (I mean when doing Debug > Compile from the IDE). Any issue at this stage must be solved.
Make absolutely sure you close all open recordsets, preferrably followed by setting their variables to Nothing. VBA is not as sensitive as it used to be about dangling references, but I found it good practice, especially when you cannot be absolutely sure that these references will be freed (especially when doing stuff at Module-level or Class-level for instance, where the scope may be longer-lived than expected).
Similarly, make sure you properly destroy any COM object you create in your classes (and subs/functions. The Class_Terminate destructor must explicitly clean up all. This is also valid when closing forms if you created COM objects (you mentioned using ADOX, scripting objects and regex). In general keeping track of created objects is paramount: make sure you explicitly free all your objects by resetting them (for instance using RemoveAll on a dictionary, then assigning their reference to Nothing.
Do not over-use On Error Resume or On Error Goto. I almost never use these except when absolutely necessary to recover from otherwise undetectable errors. Using these error trapping constructs can hide a lot of errors that would otherwise show you that something is wrong with your code. I prefer to program defensively than having to handle exceptions.
For testing, disable your error trapping to see if it isn't hiding the cause of your crashes.
Make sure that the front-end is local to the user machine, You mention they get their individual front-end from the network but I'm not sure if they run it from there or if it it copied on their local machine. At any rate, it should be local not on a remote folder.
You mention using SQL Server as a backend. Try to trace all the queries being executed. It's possible that the issue comes from communication with SQL Server, a corrupt driver, a security issue that prevents some queries from being run, a query returning unexpected data, etc. Watch the log files and event log on the server closely for strange errors, especially if they involve security.
Speaking of event log, look for the trace of the crash in the event log of your users. There may be information there, however cryptic.
If you use custom ribbon actions, make sure thy are not causing issues. I had strange problems over time with the ribbon. Log all all function calls made by the ribbon.
We have an .ocx file containing 2 ActiveX controls. One thing led to another and... now we're in "dll hell." One control loads fine within the containing application, and the other control (the one that was modified) fails to load completely. Without a doubt its because we broke compatibility by changing several event and method signatures. (That ought to teach us to unregister old .ocx's before registering new ones...)
In the past I recall having to go into the registry and manually remove important looking entries from HKCR\TypeLib, but that's scary stuff. What is the generally accepted solution to this?
If your COM registration is genuinely broken, the only way I know of to fix it is to do a search through the registry for the CLSIDs in question and delete all references to it.
Yeah, it's a little dangerous; that's why an activex control is supposed to safely register itself, and why MS now recommends using an MSI for installs and not doing a selfreg (regsvr32) in the install process. Once something gets messed up on a system, it can be a pain to fix it.
However, if you figure out the relevant CLSIDs (the CLSID for each control and the typelib) and remove only things that reference those you should be okay; to be safe, set a system restore point before you start.
Good luck
I'm new to VB6 but i'm currently in charge of maintaining a horror of editor like tool with plenty of forms, classes, modules and 3rd party tools all chunk together like the skin faces on that guy in the texas chainsaw massacre...
What i don't understand is why i get different results when i run the app in debugging mode, vs when i compiled it and run it on my devevelopment pc vs when i installed it on a different pc.
Yes i know i'm dumb, so please direct me to where i can find out more about this. I'm hoping to find out something like different linking, registry related etc connection that i'm simply not getting right now, i.e. something like wax on, wax off :P
The main pain in the neck is when i'm trying to debug some errors from my QA and i need to find a spare pc to test this on plus i can't directly debug because i don't know where the code is if i do it that manner.
Thanks.
i run the app in debugging mode vs when i compiled it and run it on my
devevelopment pc
When you compile you have the option of compiling to native code or pcode. The debugger runs using pcode only. Under rare circumstances when you compile to native code there will be a change in behavior. This particular is really rare. I used VB6 since it's release and I may get it once or twice a year. My application is a complex CAD/CAM creating shapes and running metal cutting machine and has two dozen DLLs. Not a typical situation. At home with my hobby software I never ran into this problem.
There are another class of errors that result from event sequencing problems. While VB6 isn't truly multi-tasking it has the ability to jump out of the current code block to process a event. If it re-enters the same block for the new event interesting things (to say the least) can result. I think this is the likely source of your problems as you software is an editor which is a highly interactive type of software.
In general the problem is fixed by reordering the effected areas. You find the effected area by inserting MsgBox or write to a text file to log where you are. I recommend logging to a text file as MsgBox tend to alter behavior that are timing or multi-tasking related.
Remember if a event fire while VB6 in the middle of a code block and there a DoEvents floating around then it will leave the code block process the event and return to the original code block. If it re-enters the same code block and you didn't mean for this to happen then you will have problems. And you will have different problems on different computers as the timing will be different for each.
The easiest way to deal with this type of issues is create some flag variables. In multi-tasking parlance they are known as semaphores or mutexes. WHen you enter a critical section of code, you set it true. When you leave the routine you set it to false. If it is already true when you enter that section of code you don't execute it.
when i installed it on a different pc.
These are usually the result of the wrong DLL installed. Most likely you have an older version while the target has a newer version. I would download the free Virtual PC and create a clean Window XP install to double check this.
If your problem is event timing this too can be different on different computers. This is found by logging (not MsgBox) suspect regions.
If you can display a screen shot or the text of your specific errors then I can help better.
The first thing to check would be the versions of all the dlls that your app depends on - including the service pack version of the VB6 dll.
Have you any more specific details about what's behaving differently?