It seems that once an Ocean Workstep derivative class has been released to production (and is used by clients), its name, namespace and assembly name are effectively locked for future updates (in order to ensure backwards compatibility).
When a Petrel project is saved, workstep references are saved as a full type name (namespace, class, strong assembly name) inside the binary file Classes.ptd. During loading, if the exact type name (assembly version seems to be ignored) can't be resolved, the workstep appears as "workstep not available" in the workflow editor.
In other instances of binary serialization we've encountered, Petrel makes use of the SerializationBinder registered with PetrelSystem.ProjectSerializationService - not so for Workstep instances.
Is there any other way to facilitate Workstep class/namespace/assembly renames?
Why is this behaviour so poorly documented (if at all)? Have we misunderstood something?
This issue will actually be fixed with the Ocean 2012.1 API. The workstep reference will not include the version number anymore: Both workstep and process serialization is cleaned up. Version number is not serialized (and not used on deserialization) and a UniqueId can be used instead of the type name.
Here is an extract of the 2012.1 Ocean release notes on the subject.
Process and Workstep Unique Id
Namespace: Slb.Ocean.Petrel.Workflow
Processes and worksteps created through Ocean did not have a proper identifier until now. They were identified by their full type name including the version number which means that their identifier could change, for instance, if:
- The version number of the plug-in assembly was increased (e.g. new plug-in install).
- The process/workstep class was moved to a new assembly.
- The namespace of the process/workstep class was changed.
This could cause issues in Petrel such as the display of a “broken link” instead of the process name in the Favorites tree or a workstep appearing as "workstep not available" in the workflow editor.
To solve this, Ocean has removed the version number from the process and workstep identifier and is delivering a new API to support a user defined identifier for custom processes and worksteps which will be unique across the Petrel application. Any process/workstep created through Ocean should now implement a unique identifier.
Please refer to:
- Process.UniqueId to define unique identifier for processes
- Workstep.UniqueId to define unique identifier for worksteps.
The new API also offers backward compatibility support for already serialized processes/worksteps and a few changes in the serialization logic. When a legacy project is being opened the old-style ids are automatically replaced by new ids during deserialization.
Best Regards,
Gaelle
Related
I'm doing some wrapper job with Vulkan, to make the API more safe, and I wondered if I can create an instance or device first, and enable extensions or features later.
First, according to the spec:
VUID-VkDeviceCreateInfo-pProperties-04451
If the VK_KHR_portability_subset extension is included in pProperties of
vkEnumerateDeviceExtensionProperties, ppEnabledExtensionNames must
include "VK_KHR_portability_subset"
This looks fine, but notice that to enable VK_KHR_portability_subset extension on a device, you must enable its dependency VK_KHR_get_physical_device_properties2, which is an instance extension. This makes the fact that an instance must enable VK_KHR_get_physical_device_properties2 anyway in case the 04451 will check when a device is creating.
Secondly, it will be convenient to enable features later, for example if a user passed some parameter in, which requires some features, I can implicitly enable them for this user.
Features and extensions are specified at creation time. They're an innate part of the instance or device from that point forward. They cannot be modified later.
You can create new instances or devices. But you can't change existing ones.
I built a virtual filesystem (not a namespace extension) for Windows which acts as a frontend of our document management server consisting of files and folders. In order to be able to display some metadata of the DMS objects in Windows Explorer as additional selectable columns, I successfully provided properties to the Windows Property System by implementing a COM Property Handler. Wheras normal property handlers focus on specific file types for which they feel responsible, my Property Handler adds properties to all files regardless of their type. Because Property Handlers can only be registered on the file type level, I registered my handler for about 30 types under
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertyHandlers\<.Extension>
However, I did not manage to register the Property Handler for folder objects. Since all objects in our file system are virtual I build the property store (IPropertyStore) by implementing IInitializeWithFile instead of IInitializeWithStream. The properties are requested from our DMS with the path of IInitializeWithFile acting as key and were not read from an objects content. This concept would work for folders as well.
For getting called on folders I tried to associate the handler by registering under different well known identifiers like Folder, Directory, AllFileSystemObjects and * instead of the file extension without success.
I also didn’t find anything in the MSDN documentation regarding this aspect.
Is there a way to register a Windows Property Handler on folders? Or is there some other way to add custom columns to folders in Windows Explorer?
I'm not sure if it is possible to do this.
Property handlers are clearly not the right approach, they are system wide and there can only be one per file extension. They should only be implemented by the software that "owns" the file extension and can parse the file to extract properties.
The old column handlers would have been your best bet (IMHO) but they are officially dead and you already said you can't use them.
Have you considered creating a namespace extension? Either as a root item somewhere (Desktop or My Computer) the way My Documents used to work in 2000/XP or maybe something more along the lines of how OneDrive works?
I'm not sure if desktop.ini files work in the root of a drive but it might be worth looking into. You would then find yourself in the poorly documented land of [.ShellClassInfo] and its CLSID, CLSID2 and UICLSID members. The general idea would be to act as a IShellFolder proxy on top of the "real" IShellFolder so you could create a multiplex property store. I think there are some (undocumented?) property keys you can override to change the folders default columns and tooltips as well.
There is also something called a delegated folder that allows you to play with nested PIDLs but the documentation is once again pretty useless so I'm not sure if this is something worth looking into.
A 3rd option is to pretend to be a cloud storage provider. I don't know if this gets you any closer to your goal and you would still have to implement some NSE bits to get to the point where you can layer yourself on top of the underlying IShellFolder. This feature is rather new and only documented to work on Windows 10.
The inner workings of how Explorer/IShellBrowser is connected to the IShellFolder/IShellView is one of the least documented parts of Windows. There are hundreds of undocumented interfaces. Explorer gives DefView special treatment leaving other 3rd-party implementations out in the cold.
My feeling is that there is no clean solution to implement this on top of a drive letter but you might get lucky, if Raymond Chen drops by he might have some tips for you...
I have created a CMIO (CoreMediaIO) plug-in for OS X that can access media hardware (in my case a virtual camera) using as the basis the Apple's example with SDK. Everything works perfectly but now before releasing I came across the problem of getting the unique media plug-in identifier:
There is not really much the documentation for CoreMedia.framework in general, and I'm curious is there a way to get this unique plug-in identifier in some shared database or something?
So eventually I used TSIs and got the next response from Apple:
As long as you’re properly generating the
UUID, nothing else is required to ensure uniqueness. The generation process
itself guarantees uniqueness. As for generating the UUID, the command line
tool “uuidgen” can take care of that:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/uuidgen.1.html
EDIT: See end of post for more information.
I am trying to to get plugins created via the Firebreath framework (1.7.0) to load. I am on Windows 8 in Desktop Mode using Internet Explorer 10. I've reproduced this with the built-in test FBTtestPlugin that comes with Firebreath. The failure is silent in that the object element is created, but fails to have any properties specified by the plugin. How does one go about debugging this? The Microsoft Internet Explorer Compatibility Tool reports that the plugin is failing to load.
(The FBTtestPlugin loads three plugins, hence the three errors.)
I've got other (non-FB) plugins working on the same settings (e.g. the example here: http://msdn.microsoft.com/en-us/library/dd565667(v=vs.85).aspx works fine as do all the examples from this site http://ie.microsoft.com/testdrive/browser/activexfiltering/Default.html ).
I've tried a huge combination of security settings, but here's the most relaxed set I have so far follows:
Tools / Safety / ActiveX Filtering: is unchecked
Internet Options / Security / Internet: "Enable Protected Mode" is unchecked
Internet Options / Security / Internet: is at Custom Level. Under ActiveX everything is "enabled" except restrictive properties such as "Allow ActiveX Filtering"
All sorts of security warnings are visible based on these settings.
Note: I don't intend to keep these settings. I just want to get the plugin working, then work backwards re-enabling security settings.
UPDATE
I figured this out partly and can now run the FB test FBTestPlugin. To make debugging easier for IE, I defined the registry key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\TabProcGrowth as 0 to limit the browser to use one process. Unfortunately, with IE10 both iexplore.exe in Program Files and Program Files (x86) direct to the 64-bit version of IE. This prevents 32-bit plugins from running (see http://support.microsoft.com/kb/2716529 ), and the symptom is silent failure.
However, my plugin still fails to load in IE and the retitled question above is otherwise still open. The problem is still silent load failure. However, I think it may have something to do with plugin configuration. The CLSID listed in the Compatibility Test Tool (like the example shown above) is listed as all 0's instead of a valid GUID. Moreover the registry looks funky: The key HKCR\Company.Name exists as does HKCR\Company.Name.1, but both are empty (instead of having a CLSID child as in normally working plugins). The expected GUID does exist, but under a bogus name "applications.'". I am now digging into the code that gets called when regsvr32 is run.
Thanks all!
I am providing this answer in the hopes that someone can use the result.
IE was not loading the plugin for two reasons.
1) The TabProcGrowth registry key and the 32/64 bit issue with IE 10. ( http://support.microsoft.com/kb/2716529 )
Don't define this key.
2) My plugin description used an apostrophe (e.g. "Gluttco's Plugin") and this messed up the registration of the component.
DETAILS ON 2):
I traced through the DllRegisterServer code and found that the phoney registry entries are due to the fact that my plugin description contained an apostrophe. E.g. "Joe's plugin". The generator (fbgen.py/cmake), generated a malformed FBControls.rgs file (it't didn't escape the quotes and thus contained a string literal such as (s 'Joe's cool plugin'). The DllRegisterServer code (called from regsvr32) used the contents of this file (embedded?) when (deep in atlbase.h). Oddly, the parser did not detect the error (or somehow erroneously recovered). From Process Monitor I could see a bunch of bogus keys being added, before it started adding good registry keys again.
For now Firebreath plugin descriptions should not contain apostrophes (probably other characters are illegal too). It might be sensible to make fbgen.py check for these characters and possibly escape, reject, or replace them.
Searching found this: http://msdn.microsoft.com/en-us/library/dd565667(v=vs.85).aspx
Do you have any group policies in place that could affect it? I don't think this is related directly to FireBreath, rather to the activex configuration...
I also found http://social.technet.microsoft.com/Forums/windows/en-US/90c3202c-448b-42b7-acf7-dab8dba7b000/one-or-more-activex-controls-could-not-be-displayed-because-either which has a few things you could try.
I have been asked, at very short notice of course, to implement exception logging to the Windows Application event Log in one of our products (vb.Net, framework 3.5, WinForms) using EntLib 5. In and of itself this is fine - I can get that working. However, this is for a client who wants messages in Chinese. Certain parts of the app have language resource files and I found a couple of sentences in my MS EntLib Developers Guide book which suggested that I could use an external resource to provide a localised 'friendly' message in a wrap handler within the Exception Handling Block.
Unfortunately there was no mention of how to actually achieve this but it seemed straightforward enough. I added a new resource to a resx file which lives at the project level for the project which is common to all areas of the application and re-built to project so that the satellite assemblies were built. I then specified the name of the resource in the 'Message Resource Name' field within the EntLib configuration console. the problem arises when I try and specify the 'Message Resource Type'.
I clicked on the search button and found the satellite assembly I needed, but it did not get added to the list of loaded assemblies and therefore I couldn't select it. The problem is that none of the places where I've seen this feature mentioned actually demonstrate how to get it working so I'm not sure where I'm going wrong. The search for the assembly will only let me select a dll or exe so I assume I am supposed to reference the satellite assembly somehow but how do I do this if it won't add it to the list of loaded assemblies?
One point to note is that we have a main executable which then calls numerous class libraries to load areas of functionality as required, and the config file we use throughout is the one which belongs to the main executable. Is it the case that you can only use satellite assemblies which are related to the assembly that the config file belongs to?
I haven't yet fully utilized this feature yet but just something to check, are you using the fully qualified name of the assembly?
EDIT: A potentially applicable link - http://entlib.codeplex.com/discussions/67460