Can't Use
android:showAsAction="ifRoom"
in the menu XML despite I'm using the library support v7 as jar file
note: minimum SDK is 8
Problem:
The referenced android attribute is not available. You need to use a custom namespace to explicitly reference the v7 implementation.
My solution:
<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto">
<item
...
app:showAsAction="always"
...
/>
</menu>
Related
I want to debug a xslt used in umbraco (4.0) user control. The xslt is using static .net methods from an assembly say MyAssembly. The xslExtensions.config has been setup with the following entry <ext assembly="/bin/MyAssembly" type="MyAssembly.Utility" alias="MyAssembly.Utility" />
This is referenced and used in the xslt file like
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:MyAssembly.Utility="urn:MyAssembly.Utility"....
-------------------------------------------------->
--------------------------------------------------
<xsl:variable name="Id" select="MyAssembly.Utility:GetQueryStringValue('tlid')"></xsl:variable>
The assembly is copied in the bin folder of the application
The xslt file is quite big and extensively using .net methods. I'm just wondering how can I debug the XSLT by adding breakpoints at various lines. If I run the application just like any .net application and put break points then these breakpoints don't get a hit. If I use the XSLT debug options from the Visual studio menu i.e. Start XSLT Debugging then the debugging starts but I get the error on this line <xsl:variable name="Id" select="MyAssembly.Utility:GetQueryStringValue('tlid')"></xsl:variable>
the error is "Cannot find a script or an extension object associated with namespace 'urn:MyAssembly.Utility'."
Any ideas how can we debug the xslt as explained in this MS visual studio walk-through https://msdn.microsoft.com/en-us/library/ms255602.aspx using .net methods?
I have never used XSLT so i'm probably not going to help with what I'm going to say, but since I've been doing this since day 1 why don't you use break points in Visual Studio to see what your code does? That's the only way I've needed so far in debugging my code.
In the Qt Installer Framework, all of the demos have TargetDir specification that (for Windows) place the application in, e.g., C:\InstallationDirectory. How can I have it default to Program Files?
<?xml version="1.0" encoding="UTF-8"?>
<Installer>
<Name>Your application</Name>
<Version>1.2.3</Version>
<Title>Your application Installer</Title>
<Publisher>Your vendor</Publisher>
<StartMenuDir>Super App</StartMenuDir>
<TargetDir>#RootDir#InstallationDirectory</TargetDir>
</Installer>
There is no option for this, but you can create use the Component Scripting interface to set the installation directory, as described here.
First, in your packages/com.myorg.myapp/meta/package.xml file, include this reference to the script file.
<?xml version="1.0" encoding="UTF-8"?>
<Package>
...
<Script>installscript.qs</Script>
</Package>
The installscript.qs file, which should be in the same directory as package.xml, should be the following:
function Component()
{
var programFiles = installer.environmentVariable("ProgramFiles");
if (programFiles != "")
installer.setValue("TargetDir", programFiles + "/MyPath");
}
Now the installer framework will suggest C:\Program Files\MyPath or C:\Program Files (x86)\MyPath, as needed.
Finally, if you want to allow installation paths with spaces (like C:\Program Files\MyPath), you need to enable that specifically in config/config.xml by adding this line:
<?xml version="1.0" encoding="UTF-8"?>
<Installer>
...
<AllowSpaceInPath>true</AllowSpaceInPath>
</Installer>
From Qt Installer Framework >= 3.0
You can now use the ApplicationsDir variable, and it'll default to C:\Program Files on Windows, /opt on Linux and /Applications on OS X.
<?xml version="1.0" encoding="UTF-8"?>
<Installer>
...
<TargetDir>#ApplicationsDir#/InstallationDirectory</TargetDir>
</Installer>
Reference: http://doc.qt.io/qtinstallerframework/scripting.html#applications-directory-on-windows
Is there a possibility, in any language (c/c++/c#,VB etc I DONT CARE) to export all the COM Registration information (such as clsid, progid, typelib, interface, appid etc)? Or do you know a reliable tool that exports that information including all of the 32 bit and 64 information?
Basically what I wanna do is what regsvr32 does but "in a file" and not write it to the registry. The solution can be a API-Call or Assembly class OR ANYTHING that supports me by doing this or it can be a tool where you are able to export the infos to a file. Please be aware that the tool, if so, should do this for COM as well as for interop assemblies.
(I am not interessted in wisecomcaputure or the equivalent of adminstudio)
For clarification my point is here:
I am a setup engineer. I basically want to know a way to get all the registration information of a COM or an Interop Object that's normally placed in the registry by calling regsvr32.
I am very glad of any help or hints
Eliane
There is a little-known but very handy API: RegOverridePredefKey. It allows to do exactly what you're looking for:
The RegOverridePredefKey function is intended for software
installation programs. It allows them to remap a predefined key, load
a DLL component that will be installed on the system, call an entry
point in the DLL, and examine the changes to the registry that the
component attempted to make. The installation program can then write
those changes to the locations intended by the DLL, or make changes to
the data before writing it.
Follow the docs for further details. Once you have re-mapped the HKEY_CLASSES_ROOT key and called the COM server's DllRegisterServer, use RegSaveKey to save the re-mapped key to a file, process the file and change the mapping back to HKEY_CLASSES_ROOT.
We use WiX in our company to create installers and gathering this registry information for COM assemblies is often essential in the installation process. Within the WiX suite there is a tool called Heat that basically scrapes this information and puts it in an xml file. This xml is specific to WiX but it may still help you.
An example heat command to do this would be:
C:\Program Files (x86)\WiX Toolset v3.8\bin\Heat.exe dir ..\ExactaRFBinaries\ -cg ExactaRF -dr RFINSTALLFOLDER -srd -var var.RFBasePath -gg -sfrag -suid -out ExactaRF.wxs
It's output would look something like this:
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<DirectoryRef Id="RFINSTALLFOLDER">
<Component Id="ContainerObj.dll" Guid="{A23592C5-E88D-4F56-A853-AE62085F9A91}">
<File Id="ContainerObj.dll" KeyPath="yes" Source="$(var.RFBasePath)\ContainerObj.dll">
<TypeLib Id="{8EB27E71-FA87-11D3-A3B3-00104B082353}" Description="ContainerObj 1.0 Type Library" HelpDirectory="RFINSTALLFOLDER" Language="0" MajorVersion="1" MinorVersion="0">
<Class Id="{2F467C72-FE8A-11D3-A3B7-00104B082353}" Context="InprocServer32" Description="Containers Class" ThreadingModel="apartment" Programmable="yes">
<ProgId Id="ContainerObj.Containers.1" Description="Containers Class">
<ProgId Id="ContainerObj.Containers" Description="Containers Class" />
</ProgId>
</Class>
<Class Id="{8EB27E80-FA87-11D3-A3B3-00104B082353}" Context="InprocServer32" Description="Container Class" ThreadingModel="apartment" Programmable="yes">
<ProgId Id="ContainerObj.Container.1" Description="Container Class">
<ProgId Id="ContainerObj.Container" Description="Container Class" />
</ProgId>
</Class>
<Interface Id="{2F467C71-FE8A-11D3-A3B7-00104B082353}" Name="IContainers" ProxyStubClassId32="{00020424-0000-0000-C000-000000000046}" />
<Interface Id="{8EB27E7F-FA87-11D3-A3B3-00104B082353}" Name="IContainer" ProxyStubClassId32="{00020424-0000-0000-C000-000000000046}" />
</TypeLib>
</File>
</Component>
<Component Id="ContainerUseMod.dll" Guid="{48616A97-02AA-4C02-AC5D-F41313B3C0F2}">
<File Id="ContainerUseMod.dll" KeyPath="yes" Source="$(var.RFBasePath)\ContainerUseMod.dll">
<TypeLib Id="{7590DB15-C326-11D3-99A9-0080C84E7C62}" Description="ContainerUseMod 1.0 Type Library" HelpDirectory="RFINSTALLFOLDER" Language="0" MajorVersion="1" MinorVersion="0">
<Class Id="{7590DB22-C326-11D3-99A9-0080C84E7C62}" Context="InprocServer32" Description="ContainerUse Class" ThreadingModel="apartment" Programmable="yes">
<ProgId Id="ContainerUseMod.ContainerUse.1" Description="ContainerUse Class">
<ProgId Id="ContainerUseMod.ContainerUse" Description="ContainerUse Class" />
</ProgId>
</Class>
<Interface Id="{7590DB21-C326-11D3-99A9-0080C84E7C62}" Name="IContainerUse" ProxyStubClassId32="{00020424-0000-0000-C000-000000000046}" />
</TypeLib>
</File>
</Component>
</DirectoryRef>
</Fragment>
<Fragment>
<ComponentGroup Id="ExactaRF">
<ComponentRef Id="ContainerObj.dll" />
<ComponentRef Id="ContainerUseMod.dll" />
</ComponentGroup>
</Fragment>
</Wix>
WiX is open source so you could probably look at the Heat source code if you want and engineer your own solution as well.
Yes, this is possible. However, the only tool I know of is proprietary and used internally within my company. I'm not sure exactly how it does it and I can't give out the source, unfortunately.
From poking around in the source, it seems like it's getting all the resources of COM DLLs and doing something with the resources, and it's pulling out some info from the type libraries (it's a command-line program that can be given a dll or a tlb).
The code is written in C++ and C# and is about 1400 LOC.
The code makes use of the COM interfaces ITypeLib and ITypeInfo and the TYPEATTR structure. I see calls to ITypeInfo::GetDocumentation, ITypeInfo::GetTypeAttr, LoadTypeLibEx, EnumResourceNames. The output of the program is a .reg file, which appears to be formatted by the tool's code rather than an external library.
We found a little utility called RegCap that Microsoft included with a visual studio extension called Visual Studio Installer Projects. The overall package can be downloaded from the Visual Studio Marketplace (it's a vsix file) here:
https://marketplace.visualstudio.com/items?itemName=VisualStudioClient.MicrosoftVisualStudio2017InstallerProjects
I've had a brief play and it certainly seems to extract the COM registration information. Whether it extracts all the information that regsvr32 would have put into the registry is another matter.
I am trying to get dropping a file into the application to work and so I compiled the example but every time I try to drop a file, I get the "not allowed to drop" symbol. I tried this also with my own example and in debug mode I find that none of the implemented functions (dragEnterEvent, dragMoveEvent, dropEvent) are even reached. What is the problem here / how do I fix this?
Also, running Qt 4.8 on Win7 x64
I found the issue: you cant drag and drop from a non escalated application (explorer.exe) to an escalated one.
Thanks to #HansPassant for the workaround: add a manifest file:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="true"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
This manifest requires 'uiAccess' to be true and that requires the exe to be trusted and signed.
Note: the solution proposed in http://helgeklein.com/blog/2010/03/how-to-enable-drag-and-drop-for-an-elevated-mfc-application-on-vistawindows-7/ using ChangeWindowMessageFilter does NOT work.
I am trying log some entries in a log file (Log.Trace / Log.Debug) while my VS unit test runs. I have also copied the file NLog.config to out directory through DeploymentItem attribute over class. Still my log file is not created. Any help as to how can we log entries in a file same as we do for normal web application.
I've just found a solution to this problem:
Add the App.config file to yout unit test project with the following contents:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="nlog" type="NLog.Config.ConfigSectionHandler, NLog"/>
</configSections>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<targets>
<target name="debugLog" xsi:type="Console" />
</targets>
<rules>
<logger name="*" minlevel="Debug" writeTo="debugLog"></logger>
</rules>
</nlog>
</configuration>
You may put any configuration you wish as with NLog.config file.
Unfortunately that is the only XML solution at the time. It is not only about Unit Testing, though. NLog.config does not work with just any Console Application.
Do not know if it is by design or just an oversight. Anyway I would not say that moving NLog.config to App.config section is any way satisfactory =/
Maybe it is worth to notice that there is a possibility of configuring nlog directly from code, what could be helpful in some scenarios.
One could be also glad to find nlog debug option, that will log the whole process of processing configuration file, registering targets and so on...
To turn it on, just add internalLogFile and internalLogLevel attributes to nlog element:
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" internalLogFile="C:/logs/nlog.txt" internalLogLevel="Debug">
or from code:
InternalLogger.LogFile = #"c:\logs\nlog.txt";
InternalLogger.LogLevel = LogLevel.Trace;