Is there any documentation which describes all the valid elements for a Windows application manifest, which namespace they are in, and which Windows versions will use them? All the documentation I found so far describes only parts of the manifest, and I have seen different XML namespaces used for the same element.
What I have found so far:
Manifest Files Reference/Application Manifests seems to have full documentation of the urn:schemas-microsoft-com:asm.v1 namespace plus the compatibility/supportedOS stuff (from the urn:schemas-microsoft-com:compatibility.v1 namespace). It has a link to a schema file which does not have the compatibility/supportedOS stuff.
Step 6: Create and Embed an Application Manifest (UAC) documents the trustInfo/requestedExecutionLevel stuff as being in the urn:schemas-microsoft-com:asm.v2 namespace. However, I have seen other places saying it is in the urn:schemas-microsoft-com:asm.v3 namespace.
SetProcessDPIAware Function documents an application/windowsSettings/dpiAware thing as using both the urn:schemas-microsoft-com:asm.v3 namespace and a http://schemas.microsoft.com/SMI/2005/WindowsSettings namespace.
Application Manifest XML Schemas looks like a set of schema files for some of these namespaces, but it seems to contradict the other references (for instance, unless I am misreading the xsd, dependency is in the urn:schemas-microsoft-com:asm.v2 namespace, while the first reference above implies it is in the urn:schemas-microsoft-com:asm.v1 namespace).
There's no such thing. In fact I'd bet that there are still some completely undocumented parts of the manifest. Indeed, for a long time the only documentation of the DPI aware part was in Raymond Chen's blog and book!
Related
I am trying C++/WinRT and the WinUI templates available in VisualStudio. I am confused about namespaces ::winrt::Microsoft and ::winrt::Windows. I only know about the former one because auto-generated callback functions used a type from ::winrt::Microsoft, and wouldn't compile because I passed identically named type from ::winrt::Windows namespace by mistake. I couldn't find more information about ::winrt::Microsoft, couldn't even find official documentation.
From what I can say, ::winrt::Microsoft and ::winrt::Windows have mostly identically named types, but some types are missing from ::winrt::Microsoft. For example, ::winrt::Windows::UI::Colors and ::winrt::Microsoft::UI::Colors both exist, but ::winrt::Windows::UI::Color has no "alternative" in the Microsoft namespace.
Questions:
Why do we have 2 almost the same but subtly different namespaces?
Under which circumstances do I choose one or the other?
Why ::winrt::Microsoft is missing some types?
Windows is the original namespace, where all UI-related types live. Some of those types were 'reinvented' into the Microsoft namespace as part of moving WinUI out of its UWP-only misery.
If a type is available in the (newer) Microsoft namespace then use that. The transition is not yet complete, so some types are missing.
I'm currently trying to get a rather tangled scheme running with registration free COM.
It's not that it is not working, it's that I have hit a kind of confusing situation, where it seems I should active the manifest of the assembly dependency directly in the application context, rather than have the application context point at the dependent assembly.
It is rather easy to explain by the example project MS themselves publish:
Normally, you have an application, an app manifest, a (server-)dll and it's assembly manifest. These correspond to what the example gives:
client.exe
client.exe.manifest (This one points to SideBySide.X as dependentAssembly)
SideBySide.dll
SideBySide.X.manifest
Now, one standard case is to embed the client application manifest inside the client executable, and then use the DLL and its external manifest file.
Now, if for whatever reason the correct application manifest isn't known at compile time, you can load a manifest file at runtime via the Activation Context API.
And this is where it gets confusing:
According to the article, the client application now directly switches its Activation Context to the assembly manifest:
If you look at the _tmain function in client.cpp ... a new section of code that initializes the activation context as follows:
actCtx.lpSource = "SideBySide.X.manifest";
I have cross checked this, and it would also work to dynamically load a file that contains the info from client.exe.manifest, i.e. just the reference to SideBySide.X, and continue with this Activation Context - which would also correspond to the ActCtx in use when we embed a correct application manifest into the executable.
That is, actCtx.lpSource = "client.exe.manifest"; would also work.
TL;DR What is the implication, if any, of directly activating an Activation Context "containing" an assembly manifest inside application code.
Is this how it's supposed to be done when loading manifests from files? (And if so, why can't we directly embed the assembly manifest into the executable, when it is known at compile time.)
Note: (This should really be a comment to #Eric Brown's answer, but it's getting rather lengthy)
The linked article does a decent job of explaining the two RT_MANIFESTresource types, but with regard to regFreeCOm, it leaves a few loose ends. I'll throw in some quotes that jumped at me:
ISOLATIONAWARE_MANIFEST_RESOURCE_ID is used primarily for DLLs. It
should be used if the dll wants private dependencies other than the
process default. ...
the NT library loader checks to see if the
dll has a resource of type RT_MANIFEST, ID
ISOLATIONAWARE_MANIFEST_RESOURCE_ID. If it does, the loader calls
CreateActCtx with the resource, and use the generated activation
context to probe the dll's static dependencies.
What I understand this to mean is that the only point of RT_MANIFEST/2 is for the static DLL dependency loader to find the correct resource to use for resolving DLL dependencies. (Not COM dependencies, see below.)
Sometimes, you want to use the activation context outside of probing
the dll's static dependencies. You can define macro
ISOLATION_AWARE_ENABLED when you compile the module.
When ISOLATION_AWARE_ENABLED is defined, Windows re-defines certain
APIs. For example LoadLibraryExW is redefined to
IsolationAwareLoadLibraryExW.
... Not all APIs affected by activation context are wrapped. For example,
..., and neither is any of the COM APIs.
So, to sum up: I think the RT_MANIFEST mechanism is mostly orthogonal to regFreeCOM as COM doesn't care at all where it's activation context comes from and there is no built-in help for regFreeCOM wrt. Isolation Awareness.
Yes, this is how it's supposed to be done, and you can embed the assembly manifest into the executable (well, the resource section). That's what the RT_MANIFEST resource type is for. There are two default types of manifest resources
Process manifests, with ID CREATEPROCESS_MANIFEST_RESOURCE_ID (1), used during process creation,
Isolation-Aware manifests, with ID ISOLATIONAWARE_MANIFEST_RESOURCE_ID (2), used during DLL loading.
There are a couple of uses (primarily around Click-once deployment) that illustrate the ability to embed registration-free COM manifests in subsidiary DLLs, using RT_MANIFEST. In particular, if a DLL has a CREATEPROCESS_MANIFEST_RESOURCE_ID, that manifest will be used as well.
An example seems like a good thing here.
Given
client.exe
sidebyside.dll
If sidebyside.dll has an RT_MANIFEST resource with ID 1 (CREATEPROCESS_MANIFEST_RESOURCE_ID) which has the appropriate registration-free COM entries in it, and client.exe has an RT_MANIFEST resource with ID 1 that has a <file> entry for sidebyside.dll, then Win32 will automatically handle the registration-free COM management.
Part 8 of the example article strongly implies this, and I've seen it done in a number of in-house projects.
I've developed a plug-in using the ObjectARX SDK, C# and the Autodesk plug-in templates for VS2010. The plug-in is loaded into AutoCAD at start-up via a registry entry as documented in the SDK files.
The plug-in itself is to be distributed privately and will not be submitted to the 'Marketplace' supplied by Autodesk for AutoCAD products.
I've noticed that there is a section on the AutoDesk website with regards to registering a custom prefix via the RDS scheme.
Code that differs from the default template is found within the following areas:
Namespaces e.g. "MyNamespace.Utility"
Custom Classes MyClass.cs
Custom Functions e.g. LogData()
Custom Commands e.g. "DEBUGDATA"
Based on the current implementation and intended usage/distribution method is symbol registration required? I ask as I am not sure what would happen if another plug-in used by the user has a "DEBUGDATA" command for example.
If symbol registration is required where can I find a clear example of it's implementation within code?
Many thanks
The way I try to avoid command name duplication is to use a really long command name, including my top namespace ("CadBloke" in my case) and then add a command alias to the acad.pgp file so the keyboard command is more sensible. Buttons on a toolbar etc don't care how long a command name is.
In your code, namespace clashes can certainly be an issue. I tend to make my top-level namespace pretty wordy, something like "CadBloke.CadTools.ToolName". You'd have to be pretty unlucky, or have annoyed someone, to get a clash with that sort of thing.
I saw your question on the Autodesk forum - that answer is basically the same as mine: try to make your namespace unique.
Hazy memory: I think some of the project wizards from Autodesk add your symbol to the namespace.
Here's a blog post with a link or 2 on symbol registration: http://adndevblog.typepad.com/autocad/2012/05/registered-developer-symbols.html (your link is dead, pretty typical of Autodesk as they move links around a lot). Follow that up and try & find some info on symbols. Good luck with that, I never found anything concrete. Me, I don't use it presently.
I want to add my own project type based on IronStudio. So,
I downloaded the source for and compiled the latest version of IronPython, then
I created a new Visual Studio Package.
I added the Templates\Projects\MyProject folders, and added a file to it, and set its property "Include in VSIX" to true.
Then modified the main Package class to be derived from IronStudio's PythonProjectPackage instead, and set the ProvideProjectFactory property:
[ProvideProjectFactory(
typeof(PythonProjectFactory),
"Django Project",
"Django Project Files (*.myproj);*.myproj",
"myproj", "myproj",
#"Templates\Projects\MyProject",
LanguageVsTemplate="MyProject")]
public sealed class MyPackage : PythonProjectPackage
And ran it. But MyProject isn't showing up in the project templates. Why not?
The generated .pkgdef file looks like this:
[$RootKey$\InstalledProducts\VSPackage3Package]
#="#110"
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"PID"="1.0"
"ProductDetails"="#112"
"LogoID"="#400"
[$RootKey$\Packages\{5cd7435c-7461-459f-80bc-c0c79e9d462f}]
#="Microsoft.VSPackage3.VSPackage3Package, VSPackage3, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a4f1577d825253f8"
"InprocServer32"="$WinDir$\SYSTEM32\MSCOREE.DLL"
"Class"="Microsoft.VSPackage3.VSPackage3Package"
"CodeBase"="$PackageFolder$\VSPackage3.dll"
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}]
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\Extensions]
"py"=dword:00000020
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\LogicalViews]
"{7651a701-06e5-11d1-8ebd-00a0c90f26ea}"=""
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\LogicalViews]
"{7651a702-06e5-11d1-8ebd-00a0c90f26ea}"=""
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\LogicalViews]
"{7651a703-06e5-11d1-8ebd-00a0c90f26ea}"=""
[$RootKey$\CLSID\{888888fd-3c4a-40da-aefb-5ac10f5e8b30}]
#="Microsoft.IronPythonTools.Project.PythonGeneralPropertyPage"
"InprocServer32"="$WinDir$\SYSTEM32\MSCOREE.DLL"
"Class"="Microsoft.IronPythonTools.Project.PythonGeneralPropertyPage"
"CodeBase"="$PackageFolder$\VSPackage3.dll"
"ThreadingModel"="Both"
[$RootKey$\Projects\{888888a0-9f3d-457c-b088-3a5042f75d52}]
#="PythonProjectFactory"
"DisplayName"="My Project"
"DisplayProjectFileExtensions"="My Project Files (*.myproj);*.myproj"
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"DefaultProjectExtension"="myproj"
"PossibleProjectExtensions"="myproj"
"ProjectTemplatesDir"="$PackageFolder$\Templates\Projects\MyProject"
"Language(VsTemplate)"="MyProject"
[$RootKey$\NewProjectTemplates\TemplateDirs\{5cd7435c-7461-459f-80bc-c0c79e9d462f}\/1]
#="My Project"
"SortPriority"=dword:00000064
"TemplatesDir"="$PackageFolder$\Templates\Projects\MyProject"
[$RootKey$\Projects\{888888a0-9f3d-457c-b088-3a5042f75d52}]
#="PythonProjectFactory"
"DisplayName"="IronPython"
"DisplayProjectFileExtensions"="IronPython Project Files (*.pyproj);*.pyproj"
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"DefaultProjectExtension"="pyproj"
"PossibleProjectExtensions"="pyproj"
"ProjectTemplatesDir"="$PackageFolder$\.\NullPath"
"Language(VsTemplate)"="IronPython"
[$RootKey$\NewProjectTemplates\TemplateDirs\{5cd7435c-7461-459f-80bc-c0c79e9d462f}\/1]
#="IronPython"
"SortPriority"=dword:00000064
"TemplatesDir"="$PackageFolder$\.\NullPath"
[$RootKey$\Services\{b98e41c4-581e-3532-beee-06829b683d39}]
#="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"Name"="IPythonStarter"
I just want to get the bare bones up and running so I can start overriding some functionality (like the Add New Item dialog).
Update:
Reading my initial analysis once again increases my impression that some of the required components are missing (e.g. a dedicated ProjectFactory) and/or wired up incorrectly - from the MSDN documentation of the ProvideProjectFactoryAttribute Class:
ProvideProjectFactoryAttribute declares that a package provides a project factory.
And further:
If a VSPackage declares that it provides a project factory, it should create the factory and offer it to Visual Studio in the Initialize method of the Package-derived class.
You package is declaring to provide PythonProjectFactory, but (likely) doesn't offer it to VS, rather it is offered by the IronPython package. In turn you are providing arguments within the ProvideProjectFactory attribute list which PythonProjectFactory won't know about when asked for by VS.
Consequently you should at least provide a dedicated ProjectFactory yourself as per the walkthrough, wire up the classes accordingly and see how this turns out regarding the issues outlined below.
Initial analysis:
There appear to be several issues here at first sight - have you followed any tutorial on how to do this? In case, please note that some of those easily discoverable via search engines are outdated still. Either way I'd try working through and/or comparing your result with Walkthrough: Part 1 - Creating a Basic Project System from the MSDN documentation for VS 2010; please note that even this one is claimed to be outdated a bit according to the Community Content section on the bottom of the page.
Here is what I'd look into myself given the code you present, comparing with the walkthrough on the fly for more insights:
You realized already that the duplicate fragment starting with the GUID above PythonProjectFactory doesn't make sense - this is essentially trying to register two packages at once, which, even if allowed at all syntactically (which I doubt), can't possibly work like so due to both being registered with the same GUID [cross checking with the sample file in section Examining the Template Registration confirms this suspicion, as expected there is only one such fragment].
Please note that the GUID in question is the one identifying PythonProjectFactory (as per the respective source code), see below for more on this.
[Guid(PythonConstants.ProjectFactoryGuid)]
public class PythonProjectFactory : ProjectFactory {
Given .pkgdef is a generated file the next question is where this duplication/violation stems from. When two generated artifacts end up with the same GUID the respective definition in the sources is most likely messed up somehow, usually due to copy&paste duplication. Consequently you should verify whether {5cd7435c-7461-459f-80bc-c0c79e9d462f} is defined and referenced as intended, though here might be one or two other causes as well for this, see below.
A Package class needs to be identified by a GUID and the VS wizard generates some already in Guids.cs and references it accordingly on the class definition, however, the following is missing in your fragment [cross checking with the sample fragment in section To register the project template confirms this omission as well]:
[Guid(GuidList.guidMyPackagePkgString)]
public sealed class MyPackage : Package
Likewise it appears incorrect to derive MyPackage from PythonProjectPackage but reference PythonProjectFactory still rather than providing MyFactory as well (including a dedicated GUID), because the latter tells Visual Studio the location of your project template folder [see section Creating a Skeletal Project Factory]:
While it might well be possible to simply reuse all functionality from the base class PythonProjectFactory, inheriting is likely required simply because the factory must have a dedicated GUID too (as outlined in the walkthrough) in order to properly wire up the attribute specified data.
Likely unrelated, but still suspicious is that your two code blocks don't relate, as the Package class definition specifies Django Project Files (*.myproj);*.myproj, yet the result shows My Project Files (*.myproj);*.myproj.
Have you by chance mixed this from different builds or is this really a result of a clean one?
Good luck!
This stackoverflow posting might be helpful: VS2010: VSIX installation doesn't deploy item templates inside it
If this is not what you're looking for, try to see if you're missing something around the creation of custom project templates, I believe that's where the "missing link" is:
For VS 2008:
http://blogs.msdn.com/b/webdevelopertips/archive/2008/12/02/tip-32-did-you-know-how-to-easily-create-your-own-project-templates.aspx
For VS 2010:
http://blog.reybango.com/2010/09/21/how-to-create-html5-website-and-page-templates-for-visual-studio-2010/
and on MSDN:
http://msdn.microsoft.com/en-us/library/s365byhx.aspx
and here is how to create a project
template manually:
http://msdn.microsoft.com/en-us/library/ms185291.aspx
and here is how to create a new item template in VS 2010: http://msdn.microsoft.com/en-us/library/ms247113.aspx
Hope this helps
$PackageFolder$.\NullPath may have something to do with it.
Resource scripts loaded from .rgs files are used with ATL CComModule::UpdateRegistryFromResource(). It's quite common to see samples of such files on the net but I've never seen a complete description on what constructs are allowed in .rgs files. Is there such a document?
There's some MSDN documentation, but it appears to be pretty unfocused.
The book ATL Internals talks at some length about custom replacements.
Other than that, I haven't seen much...