I have a 3rd party executable which I am trying to include in an InstallShield MSI package and I want it to have permissions set in all flavors of Windows, particularly 7 & Vista to be run as Administrator.
I'm not that clued up on the creation or the proper configuration syntax of Manifest files, but I have tried to make one manually as [appname].exe.manifest, and tried the <requestedExecutionLevel level=”asInvoker” uiAccess=”false” /> in the XML, and it didn't run as Administrator, and I want to confirm that is that because the program had not been compiled that way to see that the manifest file was in the same directory, or is it just going to be a case that the manifest file has not got the right syntax.
If there is any other simple ideas, I would love to hear it!
Cheers.
Manifests can either be embedded into an executable (this is preferred) or external, placed next to the file named as you describe. If there is an embedded manifest, an external one is ignored. For launching EXEs, this is all performed by Windows, and is not affected by code in the exe file. For loading DLLs, while this can be somewhat influenced by code you write, it does not change UAC behavior as it is not a process boundary.
As for whether a program not launching as administrator when you place a manifest requesting asInvoker next to it means you created a valid manifest, that depends on what happens when the manifest is not there. Since you mention InstallShield, you can copy a template manifest file such as its <InstallShield>\Support\setupexe.invoker.manifest to ensure your syntax is correct.
Upon re-reading your question, I realize you wanted it to launch as administrator. For that you need to request administrative rights, so you should have requireAdministrator instead of asInvoker, or base it off setupexe.admin.manifest instead.
Related
Dear Haskell community I have written my first gui application and decided to use
threepenny-gui to do so.
The task is the following search the files in a given folder for matches and provide links to open those files. In addition I made nice parse and render function as the files (mostly) have a special formatting.
But now I have stumbled upon a problem - most browsers prohibit links to local files by href="file://localhost/home/user/folder/file.pdf" being opened, for security reasons, which I do understand and find completely sensible.
I tried to use href="./file.pdf" when the program and the file are in the same folder, which also doesn't seem to work.
The code of the whole application is available at github/epsilonhalbe, I run it in a folder and access it via a browser at localhost:100000
The HTTP server provided by threepenny-gui will serve up static content from the directory you specify in tpStatic. Put your files in that directory, and make your links' paths be relative to it, and you'll be good to go!
As of threepenny-gui-0.4.*, there are also two functions loadFile and loadDirectory that can be used to serve a local file or directory at an automatically generated URL. This can be useful if the tpStatic field is not enough.
I am working on many apps that uses RegFree COM Activation, everything works well except that one of the application is ran using an older technology that uses a JIT-type compiler.
To get RegFree COM working, i have to provide a manifest to the launching executable (correct me if i'm wrong) with my dependencies listed. All my other applications are built in-house and i have full control over my manifest (authoring and if i embed it, if i leave it Side-By-Side, etc). But this JIT-compiler (ala Java JRE) isn't mine and it already contains (embedded) a manifest.
I've extracted the manifest (using MT with -inputresource and -outfile), modified it and re-embedded it. It works like expected. However, having no ownership over this executable, i am worried about the legality of such a manipulation (modifying a third party's executable and redistributing it!) and would like to avoid having to do such a thing.
Also, i am worried that at some point this executable may be signed by the third-party and thus modifying the embedded manifest is going to break the signature.
Is there a way to have the sxs-loader look for another manifest first? It seems that if it finds one embedded, it takes it by default (which under most cases is fine).
Can i provide a configuration file or anything that would skip the embedded manifest and go for my side-by-side provided one (myExe.exe.manifest, instead of RT_MANIFEST resource inside myExe.exe) ?
You can only do that system wide as far as I know. Add that to the registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide]
"PreferExternalManifest"=dword:00000001
Make sure to trip activation context cache by updating last modified date on your executable, otherwise your manifest changes won't be picked up (renaming and renaming it back seems to work).
On Win XP external manifest is preferred over internal, but since Windows server 2003 Service Pack 1 they changed it to opposite.
I worked on a chrome extension and uploaded it to chrome webstore and everything went well, I installed it on my Mac and on my Ubuntu machines in chrome it worked fine and installed. But when I try it on Windows machines, after download it popups a error message saying "Invalid Package, Can't unzip the extension".
Can any one tell me why or what might be the cause for this OS specific issue. Does it have anything to do with the permission or anything with respective folder name or content? The folder name or the extension name don't have any special characters and the previous version was fine.
Thanks in advance.
This is because there a file inside the package with a Windows invalid character in name or there a corrupted file. In my case I've tried to download the CouponsHelper extension and this error was displayed too.
I downloaded the CRX file manually and opened it with 7Zip. In the folder had a file named Icon. When I try to extract using 7Zip an error occurs too.
Note on the screenshot that there an invalid char in Icon file and that it is zero sized (possibly corrupted).
Another cause of this problem (Error: could not unzip extension) might be that you include the root directory in your zip.
You should zip all files in the same level of manifest.json.
Example
-yourappfolder
|_manifest.js
|_popup.html
In this case you should zip only manifest.js and popup.html, instead of zip the entire directory yourappfolder.
In other words, in your zip file you should NOT see the yourappfolder directory.
So the trick it to compress all the files within the folder not the folder itself.
NOTE: If it's saved in Google Drive (local syncing) this well mess it up too. Drive attaches little icons to folders that show up as unknown.
So remake the folder outside of Google Drive.
That's what was messing mine up after the "only compress inside of folder" fix.
I had the same problem but the reason was different.
I found that there is an image which has a name that is too long. When I replaced the name with a shorter one and built new package, it installed successfully.
I hope this helps anyone may facing the same problem.
A quick Google only turned up one possibly useful result but I wasn't sure if it would help.
Is that error message exactly what you see (i.e. word for word)? I couldn't find it in the code.
I may be wrong but I think this could be the code responsible for the error. Unfortunately, the zip::Unzip call can potentially fail for a number of reasons and only provides more details in the logs. I'm guessing such logs output to this location (Windows XP);
%USERPROFILE%\Local Settings\Application Data\Google\Chrome\Application\debug.log
None of this information may be useful to you but I thought I'd show you my investigation :)
Have you tried to install the extension again and do you have administration rights (not sure if this would have an affect here)?
I had the same problem but it was rejecting it because either the file was too big or the paths were too long (Windows...), which was because I accidentally included my entire node_modules directory in the .crx file.
It could be caused by a lot of things.
For me, the problem was having .xcf (Gimp) files inside the package.
The extension loaded fine when unzipped manually but showed the "couldn't unzip" error in when loaded from the Chrome Webstore.
I had problems with zipping with MacOS. There was a bunch of hidden files in the zip.
Using Windows solved it but probably taking not the default zipper in MacOS should do the same.
I had a similar problem.
My solution was:
unzip the CRX to a directory...lets say called freddy123
Rename "_manifest" to "manifest"..i.e remove the underscore.
Chrome->settings->More Tools->Extensions (Check Develop Mode Check box)
Load Unpacked extension (select freddy123 directory)
This worked for me.
I want to use MBUnit to write unit tests for my application, however I will require some configuration to be set up.
My understanding is that any App.config files I add to the unit test DLL will not be loaded. I've looked in the wiki and can't see a way, is there a mechanism for loading my configuration?
I have looked into this more by myself, I found this article.
You can do this by creating a config file as you would a regular exe (DllName.dll.config), MBUnit automatically loads this as the appropriate config file.
Recently, I encountered a very strange issue, this issue only happens in Windows XP SP3 and Vista. Here are my steps:
Create two new folders in desktop (assume folder names are A and B)
Copy Microsoft GraphEdit (graphedt.exe) application to A folder, then create a empty graphedt.exe.manifest file as well. Run graphedt.exe, you will see a error message, the graphedt.exe can’t run due to the wrong manifest.
Copy Microsoft GraphEdit (graphedt.exe) application to B folder, run graphedt.exe and close it, then create a empty graphedt.exe.manifest file, run graphedt.exe again, you will see the manifest file can’t apply to graphedt.exe. But if you change the last modified time of graphed.exe, the manifest will work again.
It seems Windows will remember the status the first time the EXE uses a manifest file, but also Windows will reset the old remembered status if you change the EXE size or last modified date.
[I'm the current SxS maintainer at Microsoft]
Good investigation Yigang. You're describing the behavior on Vista, not on XP SP3.
Probing for the existence of a manifest every time an app is run would be a performance issue, since usually apps either have a manifest or don't, and that state doesn't change much. For this reason, on Vista, the first time an application is run, we cache a bit describing "this application has an associated manifest" or "this application does not have a manifest". When you ran graphedt.exe the first time, Windows cached the absence of a manifest, and will subsequently not look for one. To reset the cache, update the last modified time on the executable.