Ok, I created an installation file for my program with InstallShield(software). I was not able to successfully install the program until I made changes to the registry as described here .NET 4 fails to install because SECUREREPAIR fails to CreateContentHash of file SetupResources.dll: for computing hash Error: 997. After making the changes to the registry, I am able to install my program. So, the registry changes are to be made before running my installer file. Can I not embed that .reg file somewhere from the InstallShield while creating the installer file so that the .reg file runs before my actual installation begins?
You can create a custom action in a script to update the registry and add to the sequence. Below is a rough example (won't work off without some tweaking).
Then add to your sequence before ISInstallPrerquisites in the UI Sequence.
STRING svCmd;
STRING svCmdPath;
begin
'For DWORD:
svCmd = "reg add " + KeyName + " /v " + ValueName + " /t REG_DWORD /d " + dataValue + " /f";
'For String:
svCmd = "reg add " + KeyName + " /v " + ValueName + " /t REG_SZ /d " + dataValue + " /f";
svCmdPath = "cmd";
LaunchAppAndWait(svCmdPath, "/c \"" + svCmd +"\"", LAAW_OPTION_HIDDEN | LAAW_OPTION_WAIT);
Does this problem occur on all computers, or just some? What OS?
What is your anti-virus softare, security suite?
Are you on a locked-down corporate SOE? (Standard Operating Environment).
Are there custom policies?
Are you using mandatory (or temporary) profiles?
Pre-Requisite: If this is the official Microsoft .NET 4 runtime installer which falls over, then I would exclude it from my own setup and deliver it as a pre-requisite alongside my main installer, or I would simply point to the web-page to download the latest version of that runtime. I much prefer the latter option since what you deliver with your package could be outdated in no time as new security hotfixes become available. Crucially: most people will probably have this runtime installed by now?
Windows Update: I might even tell the user to install via Windows Update, but that is more of a manual process with more steps. Isn't .NET 4 a mandatory Windows Update install by now?
Corporate Users: Corporate packagers will appreciate the separation of runtimes from your own package seeing as much time is spent taking pre-requisite packages out of vendor packages. They simply need some one-page documentation telling them what runtime is needed. They will have the right one pre-packaged according to their own corporate standard - and debugged of issues like you mention. There is not much need to combat the runtime setup.
Real World: You can deliver a *.reg file along with your .NET 4 installer file with a brief README.txt describing the problem you mention. Then they can deal with it if they have to, and if the problem is not seen then you avoid all the fuss. Then you add a LaunchCondition to your main setup to prevent its installation unless .NET 4 is installed.
Installer softwares usually (always ? Well instalShield has one at least) have a "Registry" feature where you can define the registry hierarchy/entries/values you wanna add.
No need of any script or reg file. All values are set up before the installation they are linked with.
Anyway, you are unlikely asked to find a work around as InstallShield already deal with it for you. Just set it up in the installer.
Related
I'm trying to quietly install a .msi file using C# without the need for any user input. I'm having trouble trying to get past the license agreement so that the installation can continue. Is there a way to pass an argument so that the agreement is accepted without any user imput?
Caution: I would avoid triggering software installation from within an application binary - unless you are making an actual setup launcher application. It can work, but it may trigger serious problems with anti-virus and malware scanners. I have seen that before. I would assume you would also need to run elevated - with admin rights - to kick off your installs (per-machine installations).
Some digressions and suggestions first: MSI can be installed via msiexec.exe commands, Powershell, DTF C# (see below), WMI, MSI API (COM, Win32).
Batch: With that said, why don't you just install using a regular batch file? The /QN switch will bypass the entire setup GUI-sequence and then there should be no need to accept any license agreements. MSI logging information (short version: open log and search for "value 3" to find errors).
This command must be run from an elevated command prompt (admin rights):
msiexec.exe /I "Installer.msi" /QN /L* "C:\msilog.log" ALLUSERS=1
Setup.exe: You can also make a WiX Burn bundle (see link for code mockup) or use some sort of other tool to make a setup.exe that will install your original application and then other components in sequence - so there is nothing to trigger to install from the application.
Interactive Install: If you want to install with some user interaction you can locate the property controlling the accept status of the license agreement and set that to the appropriate value - usually 1 - to indicate accepted license.
DTF: Now the code answer. There is a component installed with the WiX toolkit called DTF - Desktop Tools Foundation It has a number of C# classes designed to deal with MSI files via managed code. This answer explains what file to add as a reference in Visual Studio and describes the different files / assemblies of DTF briefly. Another DTF sample.
The relevant file for your described purpose is: "Microsoft.Deployment.WindowsInstaller.dll".
NOTE!
You must launch Visual Studio with admin rights to install per machine.
Add project reference to "%ProgramFiles(x86)%\WiX Toolset v3.11\bin\Microsoft.Deployment.WindowsInstaller.dll".
The below code tested in VS2017 (a more elaborate version with admin check here - zipped):
using System;
using Microsoft.Deployment.WindowsInstaller;
// RUN WITH ADMIN RIGHTS
namespace DTFTest
{
class Program
{
static void Main(string[] args)
{
try
{
Installer.SetInternalUI(InstallUIOptions.Silent);
Installer.EnableLog(InstallLogModes.Verbose, #"E:\Install.log");
Installer.InstallProduct(#"E:\Install.msi", "");
}
catch (Exception ex)
{
Console.WriteLine("Exception:\n\n " + ex.Message);
}
}
}
}
Link:
On reboot initiated issues
Install via VBScript COM, DTF, Win32
Generally you just run the msi silently like
msiexec /i foo.msi /qn
If the MSI has implemented an additional consent you might have to pass a property like
msiexec /i foo.msi /qn ACCEPTEULA=1
The exact name of this property would depend on the MSI so you'd need to consult vendor documentation or examine the MSI using a tool such as ORCA.
I've tried several ways to make it work but there seems to be no easy way. Yes, there are a ton of plugins, configurations. But they do not work right as per Oct 2019.
OmniSharp-Vim client needs configuration, it covers only C# and it lists plugins integration that does not work anymore (try choosing it for linting in ALE).
YouCompeleteMe should work but it is large and seems bloated.
Deoplete don't have source for C# and configurations I found are out of date.
Coc.nvim does not even list C# and 'unofficial' configurations have issues (like this). Besides Coc.nvim seems to be an alien from VS Code.
LanguageClient-neovim I didn't find sensible configuration and it seems because C# LSP server needs .sln file.
So this seems that csharpers should go to VS (or Rider) and that is when MS proposed LSP. How do you make IDE like from nvim to work with C#?
Basically the client should start server like this and use LSP.
~/.cache/omnisharp-vim/omnisharp-roslyn/run -s <PATH TO SLN OR DIR>
I just got omnisharp / ale working successfully with a clean install. You may want to completely uninstall omnisharp (~\AppData\Local\omnisharp-vim or ~/.omnisharp) just in case you have old versions.
You didn't mention your OS; I have this working in both Windows 10 and Mac OS. If you're using Mac OS make sure you brew install libuv first.
My Environment
Windows 10 (v1903) and Mac OS 10.14.6
Vim 8.1.2244
dotnet core 3.1 - I'd expect 3.0 to work as well
Instructions
First off, I'm using vim-plug as my plugin manager to handle installation. I installed it in both Windows and Mac OS using the bash/powershell snippets in vim-plug's README.
Then I added the following to my vimrc (~\_vimrc on Windows, ~/.vimrc on Mac OS):
"vim-plug config
call plug#begin()
Plug 'OmniSharp/omnisharp-vim'
Plug 'dense-analysis/ale'
call plug#end()
" plugin config
let g:OmniSharp_server_stdio = 1
Restart vim, and run :PlugInstall. It will clone omnisharp and ale for you.
Next, find some C# solution, and ensure the solution builds at the commandline (e.g. dotnet build should complete without errors). You also need a SLN file if you don't already have one (dotnet new sln and then dotnet sln add MyProj.csproj)
Choose a C# file and open it in vim. You should see the following notification:
If the install doesn't autostart, you can start it with :OmniSharpInstall. The install takes a minute or two of downloading in a terminal window. After the installation is complete, reopen vim and execute :cd \path\to\my\solution to ensure the working directory inside vim is correct. Then open a file with e.g. :e MyProj\Program.cs.
The server will be started automatically; don't manually start it. I get a lot of syntax errors for the first few seconds while the server is starting, after that I don't have any errors.
To pull up the autocomplete, type something like Console. then hit Ctrl-x o:
The above screenshot has vim-airline for the bottom bar -- that's not part of omnisharp and isn't required.
The above screenshots are Windows, but it's also working fine in Mac OS:
My full vimrc is available here and the source code I'm testing with is available here.
So far here is my setting for this using Deoplete, OmniSharp and ALE (full config at https://github.com/artkpv/dotfiles/blob/master/.config/nvim/vimrc) :
" Install Deoplete and OmniSharp:
" - OmniSharp/omnisharp-vim " for LSP support (like start OmniSharp server) and code actions, etc
" - Shougo/deoplete.nvim " for better autocompletion
" - dense-analysis/ale " for highlights
function SetCSSettings()
" Use deoplete.
call deoplete#enable()
" Use smartcase.
call deoplete#custom#option('smart_case', v:true)
" Use OmniSharp-vim omnifunc
call deoplete#custom#source('omni', 'functions', { 'cs': 'OmniSharp#Complete' })
" Set how Deoplete filters omnifunc output.
call deoplete#custom#var('omni', 'input_patterns', {
\ 'cs': '[^. *\t]\.\w*',
\})
" ... then goes your mappings for :OmniSharp* functions, see its doc
endfunction
augroup csharp_commands
autocmd!
" Use smartcase.
" call deoplete#custom#option('smart_case', v:true)
autocmd FileType cs call SetCSSettings()
augroup END
This question is related to my previous question.
I need to publish a C# application (that has been set up in IIS 6.0 and built in VS2010) to a desktop with win7.
I have set up IIS on my desktop well. Now I can install the application on my laptop by accessing the URL
http://myDesktopName.domain.com/MyApp
pointing to a physical location in desktop
e:\myPath\myApp\myAppService.svc
When I publish a new version of the web service, the application should get updated when I open it.
But, it gave me an error:
**the filename,directory name, or volume label syntax is incorrect**
After searching online, I found this error is normally caused by some unacccepted chars in the link. Here is the code that the msi (MS installer) needs to access and get the new version of the application.
System.Diagnostics.Process.Start("msiexec", "/favmuso \"" + myurl + "\"");
here,
myurl is http://myDesktopName.domain.com/MyApp/MyAppSetup.msi
Here, http://myDesktopName/MyApp/ is the virtual directory set in IIS 6.0 on my desktop. I can access and download it from IE in my laptop without any problems.
But, when the application notified me that a new version is available for updating the old one, I clicked the pop-up ballon on the application icon and then I got the error:
Error 123. The filename, directory name, or volume label syntax is incorrect.
If I try to access it from the C# code, I got the same error.
Then, I did a test by running
msiexec **/favmuso** http://myDesktopName.domain.com/MyApp/MyAppSetup.msi /Lv mapp_msi.log
In the log file, i found :
MSI (s) (80:DC) [18:04:33:089]: SECREPAIR: Failed to open the
file:http://myDesktopName.domain.com/mypath/\myAppSdetup (10).msi for computing its hash. Error:123
Error 123. The filename, directory name, or volume label syntax is incorrect.
Why my applcation setup file name was changed to
\myAppSdetup (10).msi
The "/favmuso" options can be found at
https://technet.microsoft.com/en-gb/library/cc759262%28v=ws.10%29.aspx#BKMK_Install
Any help would be appreciated.
thanks
So I noticed that you've asked this question elsewhere, and everyone was focused on the /favmuso piece of it.
I've been recently exeriencing this issue when trying to repair MSIs with a URL source when the original application was installed by SCCM 2012.
The workaround I found was to add a registry value at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer. The value below causes the MSI to skip the problematic portion of the repair and move on.
Name: SecureRepairPolicy
Type: REG_DWORD
Value: 1
To be a bit safer, you look into setting the registry value to 2 and using a whitelist as described in this Microsoft article: https://support.microsoft.com/en-us/kb/2918614. (Ctrl+F "Steps to opt-out the affected programs".)
I am creating Windows phone 8 application.I need to create App which uses compiled OpenSSL library.I was following standard latest library.
I am following INSTALL.W64 steps, as I don't know which INSTALL.* to be used.As my machine is 64 bit I preferred this:
To build for Win64/x64:
1 perl Configure VC-WIN64A
2 ms\do_win64a
3 nmake -f ms\ntdll.mak
4 cd out32dll
5 ..\ms\test
Using Visual Studio Command Prompt.Upto step 2 is fine.At 3rd step it fails to build and doesn't create library in out32dll Folder.It gives error like:
C:\Program Files (x86)\Windows Phone Kits\8.0\include\windows.h(182) : fatal err
or C1083: Cannot open include file: 'winreg.h': No such file or directory
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0
\VC\WPSDK\WP80\BIN\cl.EXE"' : return code '0x2'
Stop.
My question is :Is really OpenSSL supported for Windows Phone Platform.As I seen this which is true/false I am not sure.
Apart from this standard way I also tried this solution.Able to complete steps mentioned in answer.got build compiled in visual studio.Referenced OpenSSLWP8 in Windows Phone 8 Project.Compiled libeay32.
But when I try to create reference NativeCrypto nc = new NativeCrypto() I get FileNotFoundException in that library.Am I missing something?
Which solution is better or there is any other solution available so that I can build OpenSSL for WP8.
Any help is appreciated.
Thanks.
My question is: Is really OpenSSL supported for Windows Phone Platform. As I seen this which is true/false I am not sure.
Not officially.
I know one of the OpenSSL developers regularly build OpenSSL for Windows 8. I was also able to build for Windows 8. However...
I've got a bunch of patches for Windows RT and Windows Phone. The patches add three new targets, and it don't use VC-WIN64A. The added targets are VC-WP8-X86, VC-WP8-ARM, and VC-WINRT-ARM.
I added two new defines (OPENSSL_SYS_WINRT and OPENSSL_SYS_WINPHONE) so a lot of this went on:
-#if defined(_WIN32) && !defined(__CYGWIN__)
+#if defined(_WIN32) && !defined(__CYGWIN__) && !defined(OPENSSL_SYS_WINCE) &&
!defined(OPENSSL_SYS_WINRT) && !defined(OPENSSL_SYS_WINPHONE)
The cflags needed some tuning. For example, here's from Windows RT:
+ $base_cflags.= " /D WINAPI_FAMILY=WINAPI_PARTITION_APP";
+ $base_cflags.= " /FI SDKDDKVer.h /FI winapifamily.h";
And Windows Phone:
+ $base_cflags.= " /D WINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP";
+ $base_cflags.= " /AI\"$ENV{'WINDOWSMETADATA'}\"";
+ $base_cflags.= " /FI SDKDDKVer.h /FI winapifamily.h";
The Windows RT target is severely crippled. As an example of how bad things are on Windows RT: the target needed both -DOPENSSL_NO_SOCK and -DOPENSSL_NO_DGRAM because applications are not allowed to access the socket API. That makes it pretty useless SSL library since TCP and UDP was gutted.
The Windows Phone target is a little better. Windows Phone allows access to the socket API (so TCP and UDP are available), but the random number generator seeding is broken. Its broken because Microsoft does not provide CryptGenRandom or the older Win32 screen APIs that were used to scrape state. Application will need to explicitly seed from RNGCryptoServiceProvider.
You can see traces of my suffering on Stack Overflow. For example, Windows RT: where is sockaddr_in?.
We have been using click once since 2006 and now have a need to change the update location, this happened once before but we just uninstalled and reinstalled, this will now be problematic.
A solution was presented in Click Once Migrate URL, however when we tried this years ago (.NET 2.0), it failed with the app stating that the URL of the update and the URL of the client did not match raising a security risk and prevented the update from occurring and starting for that matter.
The docs state that this property can only be altered in the application manifest, but I'm not sure the approach to actually change this in an already deployed app.
I want to use a process such as the following assuming current version is 5 and deployment location is apps.mycompany.com and new location is clickonce.mycompany.com
Publish app at clickonce.mycompany.com with version 5.2
Publish app at apps.mycompany.com with version 5.1 which has bootstrapping code when the app starts up to alter the apps manifest to change the URL.
With this process the clients will then get two new updates consecutively. Infect, if I publish 5.1 to both locations it should work.
This type of thing can be solved by having the app uninstall itself, and then reinstall itself. I have done it before, although I was installing from a network location, and not a url, but it should be the same thing.
Here is a link on msdn for this solution. Go down to the section "How to programmatically uninstall a Click Once application and install a new version".
You can also check out a different version of the solution here.
This works, but it's a bit tricky. It is the only way I know of to solve this type of problem though.
EDIT If you use the information in that article, here are 2 things to watch out for.
Make sure the update for the app that is uninstalling itself is not optional. You need to make the required version be the current deployed version. Otherwise, the restore option is available and is the default for the uninstall dialog box, and the app won't uninstall itself.
Make sure in the GetUninstallString method in the DeploymentUtils class, change the DisplayName it is looking for from "TestCertExp_CSharp" to the name of your app.
use these command lines
mage.exe -Update setuptest_1_0_0_2.application -ProviderUrl http://127.0.0.1/setuptest/setuptest.application
mage.exe -Update setuptest_1_0_0_2.application -AppManifest setuptest_1_0_0_2\setuptest.exe.manifest
mage.exe -Sign setuptest_1_0_0_2.application -CertFile setuptest_TemporaryKey.pfx -Password mypassword
mage.exe -Update setuptest.application -ProviderUrl http://127.0.0.1/setuptest/setuptest.application
mage.exe -Update setuptest.application -AppManifest setuptest_1_0_0_2\setuptest.exe.manifest
mage.exe -Sign setuptest.application -CertFile setuptest_TemporaryKey.pfx -Password mypassword
Check this: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2939893&SiteID=1