In a related security.stackexchange.com question, I asked for ways to find security advisories for specific software. I'd like to automate this process, but I found a mismatch between my database of Microsoft versions that includes build numbers (like 9.00.3027.00) and actual market version names (like - let's say - 2013). How could I translate those in either way (build numbers to version names or the other way round)? Is there a library in any language that would let me do that for Microsoft products (and most preferably other vendors?)
Related
I'm developing a plugin for all JetBrains IDEs.
The plugin needs to know which exact flavor of JetBrains IDE it's running, some sort of string like "IntelliJ IDEA Ultimate", or "PyCharm Educational".
ApplicationInfo has some vague references to the IDE edition like /idea_community_about.png as the aboutImageUrl property but there doesn't appear to be anything concrete. Is there a standard way to get this data?
To get this information about the IDE, use
ApplicationNamesInfo.getInstance().fullProductNameWithEdition
From the doc string in the source:
Returns full product name with edition. Vendor prefix is not included.
Use only when omitting an edition may potentially cause a confusion.
Example #1: include the edition in generated shortcuts, since a user may have several editions installed.
Example #2: exclude the edition from "Restart ...?" confirmation, as it only hampers readability.
Rarely needed, consider using getFullProductName() instead.
As mentioned here: if you only need to know whether you are dealing with IntelliJ or PyCharm (Community or Professional does not matter) it is often enough to use fullProductName instead.
How do I find out what WSH (Active Scripting) languages are installed on a machine?
I know that JScript and VBScript are installed by default, but how do I find out if, for example, Python is installed for WSH?
EDIT
Turns out that regedit comes handy here. If you search for all OLEScript keys under Computer\HKEY_CLASSES_ROOT\CLSID, you will find their parent class IDs.
You can then identify the DLLs that implement the installed scripting engines (e.g. jscript.dll, vbscript.dll) by looking at the corresponding InprocServer32 keys under each class ID.
I suspect that's what TC (described below) is doing.
ORIGINAL
I initially (see edit above) used Take Command shell replacement (thankfully, free 30 day trial) which has a script command that lists the installed scripting engines (I was surprised to find e.g. XML to be considered a scripting engine).
Not quite what I had in mind (requires a proprietary, 3rd party payware to be installed; quite pricey at $100) but it did allow me to answer my original question: what WSH scripting engines are installed.
i'm currently in the middle of a software license review for my organization, and I am attempting to document how many instances of paid software we have installed on end-user machines.
For the example I used in the title (with Adobe Acrobat Standard vs Professional) where there doesn't seem to be any difference in the installation folder/exe, how would you suggest demarcating this within SCCM to pull the correct results?
I don't know which version of these two products you use because on our systems they have quite different installation paths (%ProgramFiles%\adobe reader vs acrobat) as well as file names (AcroRd32.exe vs Acrobat.exe).
However another method to differentiate would be the "File Description" of the executable. This or the "Product Name" should be different in any case. This is something you would see in any file inventory.
Another approach would be to rely on the data the sccm gathers regarding the entry of a software in the Add/Remove programs section of the computer. This is basically a registry entry in HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall and will most probably also show a different name for those softwares.
As you included the SQL tag in the questions I assume you want to query the database for this info. In that case a view for basic file info would be:
v_GS_SoftwareFile one for the Add/Remove Programs would be v_GS_ADD_REMOVE_PROGRAMS for example.
I am converting a C# VSTO add-in to support multiple versions of Excel (2007, 2010, 2013). My current plan is to have 4 projects in the solution, the core functionality and the AddIn projects. My question is: is it possible to write the AddIn in such a way that it will work with all versions of Excel? If not, is there a common Excel object model that would work?
If there isn't a proscribed way to do it, I would extract out the functionality from the Excel object model into a set of classes/interfaces that could then pass through an adapter to get o the real objects, then have version specific projects that contain the adapters. However, this is a lot of work I'd like to avoid.
Thanks,
Erick
Look at these two options for office version independent addins:
NetOffice is a free wrapper that does something similar to what you described in your second paragraph
Addin express is a similar (but commercial) framework
For the second option the development looks something like this:
you select the lowest version of Office you wish to support
you write the code against the object model of that version
Even with that you will still find some differences in how different versions of Excel work. For example this is one change that needs to be considered.
An application currently in development has the requirements for using MS Word to perform spell check on certain textareas within the application.
I currently have Office 2007 (which is the Office 12 com objects).
My question is, if I add in the Office 12 objects what will happen on boxes which have Office 2003? This is in regards to both other development boxes as well as the end users.
Am I correct in believing that the end result will be that the spell capabilities will not be available for those users? And if I used an Office 11 object would that mean that the users would be unable to perform the spellchecks if they have Office 07 installed?
We gave up on trying to use a dependency on Word, as both have differing versions installed or no Office installation at all! Instead opting for NetSpell.
I am guessing here, but if it is as you can't use the 2007 PIA (Primary Interop Assembly) with a 2003 installation, you could try accessing the PIA via reflection as I would guess the calls you want won't change between the two, and then it won't matter - you'll use whichever is installed. If you are installing the PIA as well, you can then either get the user to tell you which they have, or be a little more clever and just try 2007 and if it fails, try 2003.
Like I said, I'm guessing here but it might be worth a try.
EDIT: I found this link about Office PIA's. This refers to Excel but actually covers Office in general. I don't envy the task you have. Looks like you'll need to detect the PIA (which may or may not be installed) and act accordingly. Sounds like a job for reflection to me.
Newer versions of Office will maintain most if not all compatibility with older versions of COM objects. Meaning if you want to program against Office 2003 and 2007 you will need to use Office 11 COM objects as a dependency as they were the newest available when 2003 was released. As long as you verify that the methods you need exist both versions of COM objects you should have no problems as long as you use the older COM objects.
Unfortunately, although I have used this solution for my own work, I have not tested it with Spell Check. In the end make sure that you test your code with all version of Office that you wish to integrate with.
My gut reaction to this question, is to simply suggest you go another route. Try using a 3rd party spell-check control. They are relatively inexpensive (and you may find some free controls). At least that way you can control the version of the control included with your app and be able to rely on it's functionality. Quite frankly, I'm surprised this library isn't built into Windows already. Sure it's complicated with all of the languages Windows supports, but these days it's similar to copy/paste in terms of user expectations.
You can actually package both the office11 and office12 interops needed to work in BOTH versions. It takes some minor work but I managed to do it. I do a check in the registry to see which interop to call and then executes the spell checking with the correct version. It even goes so far as to check if you have Word installed and throws an error alert that you can't spell check without having Word. We're tied to using Word due to the medical dictionary that's tied into Office we're required to use.
Do a search on interop or Com wrappers and I think you'll find you can use both fairly easily.