I use 7zip to create the SFX as follows:
7z.exe a -r archive.7z *
Then I do a binary copy with the 7zS.sfx file (used to create a self extracting installer), config file "build.config", and the archive. The contents of config file are as follows:
;!#Install#!UTF-8!
RunProgram="setup.exe"
GUIMode="1"
Path="%tmp%\\mytemp"
;!#InstallEnd#!
Binary copy command is as follows:
copy /b 7zS.sfx + build.config + archive.7z sfxInstaller.exe
Problem is that the result SFX "sfxInstaller.exe" requires admin privileges for executing. Is it possible to generate Self Extracting Archives using 7-Zip that do not require admin privileges? If so, what parameters/command line arguments should I use?
Thanks in advance.
I fixed this problem with mpursuit answer.
To update manifest of 7zS.sfx you can use the following procedure:
manifest.xml
<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--application support for Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!--application support for Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
</application>
</compatibility>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86
mt.exe -manifest manifest.xml -outputresource:"7zS.sfx;#1"
copy /b 7zS.sfx + build.config + archive.7z sfx_archive.exe
You can embed a manifest file in the original 7zs.sfx that informs Windows to run the extractor with the same access token as the parent process. Which will cause the self extractor to run as a normal user if that is what the user is login as.
The following link describes how to embed a manifest file in an executable using Visual Studio 2005, but the same process applies in later versions. https://support.microsoft.com/kb/944276
Once you have embedded the manifest file that sets the "requestedExecutionLevel" to "asInvoker", any self extracting archieve created in the normal way with the modified 7sz.sfx will not require administrator privileges.
Unfortunately I have not found a way to generate SFXs using 7zip that do not require admin privileges. Having tried some other SFX generators, I stopped at IExpress that has completely satisfied my needs.
Put MiscFlags="4" in your config file. That should fix your problem.
It should look like this:
;!#Install#!UTF-8!
RunProgram="setup.exe"
GUIMode="1"
Path="%tmp%\\mytemp"
MiscFlags="4"
;!#InstallEnd#!
I don't understand how MiscFlags="4" can solve the problem.
What is the reason of the problem? You use copy /b 7zS.sfx (or 7zS2, or 7zSD, doesn't matter) with your files and it will get you a file with permissions to run only as administrator. The information what role (admin, simple user) can run the application is stored in manifest inside the application. 7zS (or 7zS2, or 7zSD) doesn't have manifest. So if you use Windows Vista or further, the result file will prompt you to enter admin credentials.
This article will help you. Read from "Getting Rid of UAC Prompt".
https://www.excelsiorjet.com/kb/35/howto-create-a-single-exe-from-your-java-application
You can fix the problem using resource editor software such as ResEdit. You should add a manifest to the 7zS.sfx file with the security information:
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
You can use 7zsd.sfx instead of 7zs.sfx.
This will not require admin privileges.
it worked fine thanks for the help
but I used
call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86
mt.exe -manifest manifest.xml -outputresource:"7zSD.sfx;#1"
copy /b 7zSD.sfx + config.txt + techselfsupport.7z techselfsupport.exe
Related
I'm using the Microsoft Team Foundation Server to manage and Deploy Setups for my Applications.
My Setups are WiX-Setups with relative Paths.
p.e.
Components
<Component Id="Anwendung.exe" Directory="INSTALLLOCATION" Guid="*">
<File Id="Anwendung.exe" KeyPath="yes" Source="$(var.SourceFiles)\Anwendung.exe" />
</Component>
Variables.wxi:
<Include>
<?define SourceFiles = "..\OutputFiles"?>
</Include>
Setups are building correctly.
The Problem: I'm using Torch and Pyro to generate Patches for my applications.
I'm using a pure Wix Patch Project with manipulated build events and additional linker information
(Pre Build - Torch)
(Post Build - Pyro)
(Linker additional Parameters - output as wixmsp)
When I build my Patch, I'm getting 579Failures.
(1x)
Error 776 The command ""C:\Program Files (x86)\WiX Toolset v3.8\bin\pyro.exe" Patch.wixmsp -out Patch.msp -t AnwendungBaseline diff.wixmst" exited with code 103.
C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets
and (578x)
Error 322 The system cannot find the file '..\SourceFiles\Anwendung.exe'. C:\Patch\Client\Upgrade\Setup\ComponentMain.wxs
I'm sure it's not resolving the paths from the sourcesetups correctly.
Could anybody help me? Rob Arnson , Rob Mensching, Heath Steward? Please :)
To get around issues like this, you can write a custom build activity for TFS to update variables in your WiX config file with fully qualified paths. For instance, you can create a build activity that takes in the path to a config file, the name of a variable, and value for that variable, and then write the new value to the config file. You can keep the config file with relative paths checked into source control, but then the build will update the config file to use the fully qualified path just for the build.
If you are unfamiliar with creating custom build activities, there is a great blog series on it here. The link is for TFS 2010 but the process is similar for TFS 2012.
I have an MsBuild Build in TFS that is publishing a web zip package.
This is the command line I am using:
/t:Build;Package
/p:DeployOnBuild=true;Configuration=Release;
DeployTarget=Package;PackageLocation=\\xxx\MyApp.zip
It is working properly and it is also replacing in the web.config the parameters as expected.
The only issue I am facing is the permissions applied to the package file.
Right now the file is deployed into:
* \myshare\myapp\ *
And the folder is set with the permission:
Everyone: full control
The package inside the folder has the permission:
TFSAdmin: full control
and nothing else, so I can't open it or copy it ... Is there any way I can avoid that?
So far it seems that the problem can't be fix if not with a workaround.
I have found an easy and simple workaround by executing in the workflow a batch file at the end of the build process.
In the batch file I use the very old ICACLS to re-set the permissions:
ICACLS \\xxx\MyPackage.zip /GRANT Everyone:F
ICACLS \\xxx\MyPackage.zip /GRANT Users:F
Add in MSBuild .proj file:
<Exec Command="icacls "\\xxx\MyApp.zip" /grant User:F" ContinueOnError="true" />
a sequence of simple rights:
F - full access
M - modify access
RX - read and execute access
R - read-only access
W - write-only access
In case you want to make a folder accessible by your website you can place the following snippet in your "PostBuild" events at the very bottom of your .csproj (you need to edit the .csproj file manually via a text editor):
<Target Name="AfterBuild">
<!-- grant everyone the modify right recursively even for files and folders created dynamically in the future -->
<!-- note the use of (OI) and (CI) flags which stand for object inherit & container inherit these flags -->
<!-- indicate that subordinate containers will inherit the same access control element or ace this means that -->
<!-- files and folders created in the future within the targeted folder will get the same permissions -->
<Exec Command=" icacls ".\Logs" /grant Users:(CI)(OI)M /T " ContinueOnError="true" />σ
<Exec Command=" icacls ".\Logs" /grant IIS_IUSRS:(CI)(OI)M /T " ContinueOnError="true" />
</Target>
Sidenote: If you use publish/deploy-on-remote-server functionality of visual studio to deploy your website, then it goes without saying that the folder permissions will probably NOT be preserved and that you will have to use some sort of post-installation script to re-apply them (probably using the 'icacls' approach again show here). This sort of post-installation script should probably be part of WebDeploy - haven't used WebDeploy myself though so your mileage may vary on this particular aspect.
This is my Ncover task portion in my MSBuild script
<UsingTask TaskName="NCoverExplorer.MSBuildTasks.NCover" AssemblyFile="$(Libraries)\NCoverExplorer.MSBuildTasks.dll"/>
<Target Name="NcoverCoverage">
<NCover ToolPath="C:\Program Files\TestDriven.NET 3\NCover\1.5.8"
CommandLineExe="C:\Program Files\TestDriven.NET 3\NUnit\2.5\nunit-console.exe"
CommandLineArgs="MyTestProject.dll"
WorkingDirectory="MyWorkingDirectory"
LogFile="coverage.log"
/>
</Target>
This NCover task executes fine and creates an output xml file (Coverage.xml). This output xml file contains a reference to a xsl file (Coverage.xsl) which is missing in my machine.
<?xml-stylesheet href="coverage.xsl" type="text/xsl"?>
I cant find this file anywhere. Due to this, hen I try to open the Coverage.xml file, it throws an error
The XML page cannot be displayed
Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later.
Access is denied. Error processing resource 'file:coverage.xsl'.
Where can i find my coverage.xsl file?
Thanks.
The coverage.xsl file is available in the install directory (C:\Program Files\NCover) once you install the NCover Community Edition located here:
http://www.ncover.com/download/current
NCover Support
TFS 2008, VS 2008.
I have a tfsbuild.proj and tfsbuild.msp file in $/MyStuff/TeamBuildTypes/Dev folder.
I have a targets file at $/MyStuff/TeamBuildTypes/IncludeFiles/Common/test.xml.
test.xml contains an XML fragment that overrides the BeforeGet task.
I tried to get the file into my tfsbuild.proj file like this:
<Import Project="$/MyStuff/TeamBuildTypes/IncludeFiles/Common/test.xml" />
The build fails because it tries to get the file from a relative path that is way off.
I have shifted gears a little and am now trying an Exec task to get the file from TFS into the local filesystem.
<Exec WorkingDirectory="$(SolutionRoot)" Command=""$(TF)" get "$/MyStuff/TeamBuildTypes/IncludeFiles/Common/test.xml" /version:W$(WorkSpaceName) /overwrite /force /noprompt /recursive" IgnoreExitCode="true" />
I have no idea where the file is going. I don't get an error. I have access to the $(SolutionRoot) variable but the TeamBuildTypes folder is above that one in the filesystem. How can I get to this file and use it as an overrride to my task for the current build?
Help?
Thanks!
That's not a "remote" path. It's a path into TFS source control. It can only be understood by TFS.
MSBUILD is not part of TFS - it's part of the .NET SDK. It can only understand the kind of paths all programs can understand.
You'll have to fetch this file from source control onto the build machine, and reference it with a path to where you fetched it.
One of my Executables writes some configuration into a XML file to C:\Program Files\MyApp\config.xml. It needs to run as Administrator on Vista / Server 2008, otherwise the OS won't let it write to that location.
I included a manifest file named config.exe.manifest, to automatically request administration rights at launch.
Here's my manifest file:
<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" />
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
I tried this on Windows Server 2008, but the manifest file seems to be ignored and the executable is launched without sufficient rights.
http://blogs.msdn.com/junfeng/archive/2009/05/11/internal-manifest-vs-external-manifest.aspx
quoted from above link:
In Windows XP, Sxs searches external manifest before internal manifest. If an external manifest is found, the internal manifest is ignored.
In Windows Server 2003 and later, the order is reversed. Internal manifest is preferred over external manifest.
If you use external manifest, and your scenario works in Windows XP, but not Windows Server 2003 and later, please double check the executable does not have an internal manifest
This will drive you batty - got to the bottom of it and posted an article and some utilities to help with your manifest being ignored: Find Out Why Your External Manifest Is Being Ignored.
Ok it works when I embed the manifest file using MT.EXE. Still don't why it doesn't work when I provide the manifest as a separate file, but I guess embeding is a good enough solution.