I know how to load unpacked Microsoft Edge extension.
Now I have my extension packed (but not signed yet) to a .appx file. Can I load the extension via the .appx file?
I tried to open the .appx file by double-click on it, it shows:
Installation failed
Reason: This one isn't signed with a trusted certificate.
Yes, you can install an Edge extension from a package, but it must be signed by the certificate which should be added to the trusted people store as described in the documentation. Well, I see, that you have a problem with signing, so you can try to use this extension sample, which contains .bat file to build a package and sign it (Visual Studio 2015 is required - see the second line of build.bat). I have published this sample to report about the bug. Hope this will help you.
Related
Due to the administrative privilege of the application, I need to install my program including .exe and .dll in C:\DestFolder\SubFolder\ but I keep getting C:\Program Files\\[Manufacturer]\\[Product Name]\ where the placeholders are specified in the properties window.
I tried this article but no good.
Please don't give me answer like try changing the defaultlocation to C:\Destination\ of the Application Folder as I have already tried. Also I don't want solution like just change the installation destination path manually during the installation.
I have found the answer from this article:
"[ProgramFilesFolder] is built in, and correctly leads to the Program Files directory on the target machine, no matter how customized the setup of Window is..."
There might be tools out there that allow installing outside of Program Files.
[Edit] Infact I've found out this great extension for VS 2017 community called Wix. There's a guy who did a fabulous tutorial on it.
I am using visual studio 2017. I am not a developer. I am just trying to write a simple parsing script and I am familiar with visual studio. I use Atmel Studio(which is based off VS) to write embedded code, but I don't have to deal with signing. I installed visual studio on my work computer and now I get bit9 errors every time I make a new build.
Internal IT has pointed me to a bunch of slightly outdated certificate stuff. I now have a certificate to apply to my builds, however the process defined here will apparently not work for a Win32 application. I do not have a Signing tab in the project properties.
I have also looked into the visual studio command line using signtool. However, it would take a lot of my time to learn how it works and implement it.
Hopefully someone else has solved this and I can save the time. If there are no easy solutions I'll just go back to manually parsing, because this has already taken up to much of my time.
This is how i've done this with Visual Studio 2010 and Visual Studio 2015 for unmanaged C or C++ Win32 applications. You need:
A signing certificate. This is normally given as a PFX when working in Windows, and is typically an intermediate certificate in your certificate chain.
The password to the above PFX to decrypt the certificate private key.
With those, the following custom build step for your Win32 project can be created:
"$(FrameworkSDKDir)bin\x86\signtool.exe" sign /v /f "path-to-your-cert\yourcert.pfx" /p password "$(TargetPath)" > "$(OutDir)sign\$(ProjectName)-sign.out"
This will use your certificate to sign the project output (be it a DLL or EXE makes no difference), and record the output of the signing certificate in a file named after your project with the suffix sign.out, placing that file in a folder called sign off your output directory.
That may seem a bit overkill, but there is a reason for that generated output file. By creating that file, and naming it as one of the "Outputs" of the custom build step:
it can be comparatively used to determine whether to re-sign or not. Each time the project is built, if the target image (your exe or dll) is regenerated that output file will be out-of-date and the custom build step will be kicked off to regenerate it (and thusly also re-sign the image). The sign.out file, btw, will contain something like this:
The following certificate was selected:
Issued to: The Signing Cert Name Here
Issued by: The Issuer Cert Name Here
Expires: Sat Dec 31 16:59:59 2039
SHA1 hash: 232C80E19EBC71330E7C12CA8C07B345B1531777
Done Adding Additional Store
Successfully signed: full-path-to-image-here
Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0
Once you have your PFX and password, you can easily just hand-test the command before you finally configure it as part of the build. The only real wildcard I've seen is the full path to the signtool.exe, which seemingly changes from time to time (different with VS2008 than with VS2015, for example.
Anyway, that's how I did it. Hopefully you can too.
I am using InstallShield 2015. When I open the Install Script project (ISM file) I do not see where I can set Template Summary property under General Information or any other tab. (I want to make it a 64 bit-only installer.)
I can set it under General Information tab when I open the MSI file but the MSI file gets overwritten every time I build the ISM file.
Is it possible to set it in the ISM file?
You're not clear about your edition of InstallShield, but as you mention opening the built .msi file, I'll assume you are using Professional or Premier. In those editions, you can set the architecture portion of the Template Summary property to 64-bit by replacing Intel with x64 in either the Summary Information Stream section of the General Information view, or in a Product Configuration in the Releases view. The latter overrides the former, so if you inherited a project that used the latter, you might think the former is failing.
See Targeting 64-Bit Operating Systems with Basic MSI and InstallScript MSI Installations in the InstallShield help for this and additional information.
I am getting a different error from this post (KNIME 3.2 Tableau Node error). I believe my problem precedes his. I suspect my problem is in setting up my dependencies and PATH variables.
I have downloaded the Tableau SDK, and placed it both in the KNIME Workspace, and in Tableau's program files. I have configured the linked resources page of the KNIME to point to each file individually and to the bin directory.
In addition, I have edited the Windows System variable PATH and added in the new \BIN\ directory;
I have also downloaded the Visual C++ Redistributable Packages for Visual Studio 2013, the 32 bit version I found from here:
https://www.microsoft.com/en-us/download/details.aspx?id=40784
When I execute I first get a library not found. Then on subsequent executions I get the error "Execute failed: Could not initialize class com.tableausoftware.extract.ExtractAPI"
Does anyone know how to properly set up KNIME's environment to successfully use the Tableau connector?
Okay here are the steps I used in order.
Download the Java version of the Tableau SDK for Windows:
https://onlinehelp.tableau.com/current/api/sdk/en-us/help.htm#SDK/tableau_sdk_installing.htm%3FTocPath%3D_____3
Unzip that file into a directory called SDK in the workspace you are using. For me this was C:\Users\<'user name'>\knime-workspace\
Update environment variables for "Path" on your system and in KNIME add a linked folder resource (Preferences -> Workspace -> Linked Resources)
Point both towards the \bin\ sub-directory.
THEN installed the "Microsoft Visual Basic 2013 Redistributables" file.
I am trying to learn to print using GDI.
I have searched MSDN for resources and found this example.
I like the thought of putting printing in separate thread, and using GDI is easier for me to learn than using XPS API so I have downloaded the example.
After trying to compile it ( I use Visual Studio 2008 ) I get this error:
fatal error C1083: Cannot open include file: 't2embapi.h': No such file or directory
According to this, I have found out that I am not the only one facing this problem.
Still, I have tried to Google the above error and found this that indicates me not having the latest SDK.
I have searched in C:\Program Files\Microsoft SDKs\Windows and found a folder v6.0A which indicates that I do not have latest SDK installed.
However, here I have found one post where person with the same problem did not solve it by downloading the latest SDK ( although the year that post was made is 2006, still the file was missing then too, and downloading the SDK didn't help-why should anything change now? ).
My question is:
Is there a way to get this file ( if I am wrong about downloading the latest SDK please correct me ) ?
I think that this file has to do something with fonts-is there a way to modify the example so I do not have to use that file?
Thank you for you rime to view this thread and for trying to help.
Best regards.
T2Embapi.h is supplied by the Windows SDK, it contains declarations for the Font Embedding Services Library to handle embedded OpenType fonts. Clearly the SDK version you use is too old to have it. Not exactly sure which version is required, I know that v6.0 doesn't have it but v7.1 does.
There's some sloppiness in the project due to it starting as an XPS sample. T2Embapi isn't actually required to build the GDI sample. You can simply delete the #include from stdafx.h. Also some sloppiness in the Release configuration settings of the project, remove T2embed.lib and XpsPrint.lib from the linker's Additional Dependencies setting.
Your question is:
1.
Is there a way to get this file ( if I am wrong about downloading the latest SDK please correct me ) ?
The latest version of Windows SDK is for Windows 8.1. Windows Software Development Kit (SDK) for Windows 8.1. However, I think the 't2embapi.h' have already included Windows SDK for Windows 7, because I found the header file in 'C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include'.
2.
I think that this file has to do something with fonts-is there a way to modify the example so I do not have to use that file?
#Hans Passant has already answered about that.