I have a problem regarding the download of a ClickOnce application.
I have succesfully deployed my ClickOnce application to an IIS server. The ClickOnce files are in path on the IIS:
/MyApp/install
When i from another machine navigate to the standard publish page of the ClickOnce I can either click "launch" or install.
The difference is:
- "launch" URL is to ThisIsTheApplication.application file.
- install URL is to setup.exe file
When I click the launch file I can succesfully install the apllication. If I use the setup.exe it fails when i try executing that file.
The setup.exe basicly checks whether my prerequiteses are installed or not (only .NET 4.5 for this).
The log file says:
The following properties have been set:
Property: [AdminUser] = true {boolean}
Property: [InstallMode] = HomeSite {string}
Property: [NTProductType] = 3 {int}
Property: [ProcessorArchitecture] = AMD64 {string}
Property: [VersionNT] = 6.2.0 {version}
Running checks for package 'Microsoft .NET Framework 4.5 (x86 and x64)', phase BuildList
Reading value 'Version' of registry key 'HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Full'
Read string value '4.5.51641'
Setting value '4.5.51641 {string}' for property 'DotNet45Full_TargetVersion'
The following properties have been set for package 'Microsoft .NET Framework 4.5 (x86 and x64)':
Property: [DotNet45Full_TargetVersion] = 4.5.51641 {string}
Running checks for command 'DotNetFX45\dotNetFx45_Full_x86_x64.exe'
Result of running operator 'ValueEqualTo' on property 'InstallMode' and value 'HomeSite': true
Result of checks for command 'DotNetFX45\dotNetFx45_Full_x86_x64.exe' is 'Bypass'
Running checks for command 'DotNetFX45\dotNetFx45_Full_setup.exe'
Result of running operator 'ValueNotEqualTo' on property 'InstallMode' and value 'HomeSite': false
Result of running operator 'VersionGreaterThanOrEqualTo' on property 'DotNet45Full_TargetVersion' and value '4.5.50709': true
Result of checks for command 'DotNetFX45\dotNetFx45_Full_setup.exe' is 'Bypass'
'Microsoft .NET Framework 4.5 (x86 and x64)' RunCheck result: No Install Needed
Launching Application.
URLDownloadToCacheFile failed with HRESULT '-2146697208'
Error: An error occurred trying to download 'https://myurl.com/MyAppFolder/install/ThisIsTheApplication.application'.
Why does the "launch" work and not the setup.exe?
I had the same problem here. My log file looked very similar (there were no stack traces or anything in it) and the last two lines were similar. The setup.exe failed, but the … .application URL worked ok. I'm on a corporate network/domain and our system administrators had set up a lot of group policies overriding the default security zone settings. The problem was solved by removing the policies and then clicking buttons:
“IE -> Tools -> Internet options -> Security -> Reset all zones to default level”
and “Advanced -> Restore advanced settings”.
I've found the following guide here:
http://feedback.veodin.com/knowledgebase/articles/52576-installation-fails-with-error-message-urldownload
Start Microsoft Internet Explorer by pressing Win+R, enter ‘iexplore’ and finally press enter
Go to ‘Tools’ Menu
Make sure to uncheck the mark at ‘Work Offline’
Execute KeyRocket_Setup.exe again
With that said, I think it's easier to create someone's own "clickonce" experience, in order to avoid any interference with Internet Explorer whatsoever.
Related
I am making use of the following code:
status = await Permissions.RequestAsync<Permissions.LocationWhenInUse>();
... before trying to make a call to:
Geolocation.Default.GetLocationAsync()
... when run using the Windows simulator the following exception was raised:
An exception of type 'Microsoft.Maui.ApplicationModel.PermissionException' occurred in System.Private.CoreLib.dll but was not handled in user code
You need to declare the capability `location` in your AppxManifest.xml file
... ok, so I add the following to the file: Platforms\Windows\Package.appxmanifest
<Capabilities>
...
<DeviceCapability Name="location"/>
</Capabilities>
... run again using the Windows simulator and status always returns with a value of PermissionStatus.Denied.
According to the documentation regarding permissions on Windows states:
Permissions must have matching capabilities declared in the package
manifest. Permission status defaults to Unknown in most instances.
Question:
How (and where) does one change the "Permission status defaults"?
Thanks in advance.
When using the Windows simulator, you need to change the App Permissions / Location settings on your development machine, as follows:
In the Windows taskbar use the Search option and enter "Location".
Select "Location privacy settings" (system settings). Make the following changes:
You can also enable or disable Location permissions for your app as shown below:
When the above settings are changed to an "on" state, calls to Geolocation.Default.GetLocationAsync() will complete successfully.
Hope that helps anyone else as green as me!
Update: 21-Sep-2022 - another Gotcha!:
The above will allow Geolocation.Default.GetLocationAsync() to complete successfuly when using the Windows Simulator ONLY if the request is made on the MainThread (it works on the Android simulator without having to be on the MainThread).
See my other post regarding this issue for further details.
My development machine is a VirtualBox with Window Server 2008 R2.
We are using CRM2011 with roll-up 12.
For my development I use framework 4
From CRM I call an aspx-page, this page contains a grid with records I can select. After I made a selection, I press a button and passes the selection to an assembly. This assembly has a function that checks if a certain key in the registry is available. If so it continues, if not it returns.
The problem I'm facing here is that I receive an error trying to read the registry using OpenSubKey() telling me that I'm not authorized to do so. I use code below to retrieve the key. The assembly is not signed. Signing the assembly doesn't change the result.
RegistryKey localKey = null;
if (Environment.Is64BitOperatingSystem)
{
localKey = RegistryKey.OpenBaseKey(Microsoft.Win32.RegistryHive.CurrentUser, RegistryView.Registry64);
}
else
{
localKey = RegistryKey.OpenBaseKey(Microsoft.Win32.RegistryHive.CurrentUser, RegistryView.Registry32);
}
Doing the same thing from a console application using the same assembly is giving no problems.
Regards,
Martin
Verify that your ApplicationPool identity has read access to the registry key in question.
Check what User your Application Pool is using in IIS then open the registry key in Regedit and check the permissions.
I need to read or change the value of "Enable32bitAppOnWin64" in the IsIISProperty table from within a custom action. Now while I can access properties from the Property Manager by Session.Properties("PropertyName")
I can't see how to do the same for the property tables.
I have tried {ISIISProperty1}, [ISIISProperty1] and Session.Properties("ISIISProperty1") all with no success.
How do I achieve this?
Any help will be appreciated.
Thanks
I haven't been able to find any information on accessing properties from installer tables in a custom action. What I did find out was that you can write some installer SQL syntax to update the tables from custom actions, but this was overkill and I couldn't get it to work.
What I have been able to do is use property substitutions with the ISIISProperty table.
I created two new properties in the Property table called ASPBITNESS and ALLOWTHIRTYTWOBIT which are set to x86 and true respectively by default.
Then I edited the ISIISProperty table in the direct editor and replaced the values for Enable32bitAppOnWin64 and AspNetVerBitness with [ALLOWTHIRTYTWOBIT] and [ASPBITNESS] respectively. Interestingly, the Enable 32-Bit Applications setting shows "No" in the InstallShield designer, even though the [ALLOWTHIRTYTWOBIT] property is set to true by default.
Finally, I have a custom action that conditionally (NOT REMOVE and VersionNT64 and IIS_VERSION > "#6") fires at the very start of the install to change those values accordingly.
The custom action code code is:
On Error Resume Next
' change the properties for x64 systems
if SYSINFO.bIsWow64 <> 0 then
Session.Property("ASPBITNESS") = "x64"
Session.Property("ALLOWTHIRTYTWOBIT") = "false"
end if
Before the MSI logs showed:
InstallShield 12:09:19: SetVRootProperties for virtual directory
'MyWebApp', app ''
InstallShield 12:09:19: IIS7 check for ASP.NET version bitness on application pool
'MyAPPPool', install is requesting 'x86'
...
InstallShield 12:09:19: SetAspversion: machine is 64-bit and
IIS running in a bit mode other than the currently selected mode
...
InstallShield 12:09:19: Error with IISRT: -2172
...
CustomAction ISIISInstall returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
After these changes the applications install and the logs now show:
MSI (s) (D4:1C) [10:53:18:662]: Doing action: Set64Bit
Action 10:53:18: Set64Bit.
Action start 10:53:18: Set64Bit.
MSI (s) (D4:0C) [10:53:18:678]: Created Custom Action Server with PID 912 (0x390).
MSI (s) (D4:D0) [10:53:18:709]: Running as a service.
MSI (s) (D4:D0) [10:53:18:709]: Hello, I'm your 32bit Impersonated custom action server.
MSI (s) (D4!1C) [10:53:18:725]: PROPERTY CHANGE: Modifying ASPBITNESS property.
Its current value is 'x86'. Its new value: 'x64'.
MSI (s) (D4!1C) [10:53:18:725]: PROPERTY CHANGE: Modifying ALLOWTHIRTYTWOBIT
property. Its current value is 'true'. Its new value: 'false'.
And then:
InstallShield 10:53:20: SetVRootProperties for virtual directory
'MyWebApp', app ''
InstallShield 10:53:20: IIS7 check for ASP.NET version bitness on application pool
'MyAppPool', install is requesting 'x64'
InstallShield 10:53:20: Application pool Enable32bitAppOnWin64 value is 'false'
InstallShield 10:53:20: ASP.NET version can be set for 64-bit.
InstallShield 10:53:20: Configuring ASP .NET version:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ir
I'm following the vfp web service walk-trough. But when I test the result in the task pane i receive an error. It was :
Error: 1429 - OLE IDispatch exception code 0 from WSDLOperation: WSDLOperation:Instantiating the dispatch object for method xxxx failed HRESULT=0x80040154: Class not registered.
xxxx is my method.
I've registered the dll and set the authorisation in IIS.
Any suggestion?
sounds like when the VFP module was compiled, the "OlePublic" class instance never was properly put into the Windows Registry. Sometimes VFP will NOT register if you not in an administrative level to allow writing to the registry. If that is the case, make sure you start VFP as "Admin" user before compiling the app.
Also, are you building it as a single or multithreaded DLL instance. In addition, if you right-click / "Project Info" of your project, and click on the "Servers" tab, it should show all your OlePublic classes. What is the "Instancing" setting... single / multi?
Additionally, it could be a "permissions" thing. If the service you are trying to load it as (ie: ASP.NET user account or similar) and that user doesn't have permissions and/or access to the file, then it won't allow the object to be created.
To just TEST if the object is in the registry or not, you could always just start an instance of VFP, and from the command window, try to do a
objTesting = CREATEOBJECT( "YourClass.YourObject" )
if it works that way, then I would look more into the permissions avenue.
FOLLOW-UP
#wongchungyie, I'm not sure of if that was the problem or not, but more likely permissions. One time, when changing development machines, I too had a problem trying to create an instance of my OlePublic COM server class. TO ENSURE what the problem was, I started a simple program in VFP that did nothing BUT
set procedure to YourClassThatHasOlePublic
set step on
o = createObject( "YourOlePublicClass" )
Then, as the "CreateObject" is going through all the initialization, you might find some "path" is not available, or permissions, or whatever... Find and fix that element and I was able to continue work for my client.
Hope this gives you something to work with.
I want my MVC3 web application to access %APPDATA% (e.g. C:\Users\MyUsername\AppData\Roaming on Windows 7) because I store configuration files there. Therefore I created an application pool in IIS with the identity of the user "MyUsername", created that user's profile by logging in with the account, and turned on the option "Load User Profile" (was true by default anyway). Impersonation is turned off.
Now I have the problem that %APPDATA% (in C#):
appdataDir = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
resolves to c:\windows\system32\inetsrv instead of C:\Users\MyUsername\AppData\Roaming.
UPDATE: More exactly, the above C# code returns an empty string, so that Path.GetFullPath(Path.Combine(appdataDir, "MyAppName")) prepends the current path to my application name, resulting in c:\windows\system32\inetsrv\MyAppName.
I know I made this work before with the same web application on a Windows Server 2008 R2, and now I'm getting this problem with the same major version 7.5 of IIS on my Windows 7.
I used the same procedure as before: Created a new user, logged in as that user to create the profile and APPDATA directories, then added the application pool with this identity and finally added the web application to this pool.
Any ideas?
Open your %WINDIR%\System32\inetsrv\config\applicationHost.config and look for <applicationPoolDefaults>. Under <processModel>, make sure you don't have setProfileEnvironment="false". If you do, set it to true.
Application Pools - Your application Pool - Advanced settings ...
Process Model - Load user Profile set True.
It Helps me.
Taken from
https://blogs.msdn.microsoft.com/vijaysk/2009/03/08/iis-7-tip-3-you-can-now-load-the-user-profile-of-the-application-pool-identity/
I experienced the same problem recently. As mentioned by Amit, the problem is that the user profile isn't loaded. The setting is for all application pools, and is in the applicationHost.config (typically C:\Windows\System32\inetsrv\config\applicationHost.config). If you update the applicationPoolDefaults elements as follows, it will work;
<applicationPoolDefaults managedRuntimeVersion="v4.0">
<processModel identityType="ApplicationPoolIdentity" loadUserProfile="true" setProfileEnvironment="true" />
</applicationPoolDefaults>
We've tried this with IIS 7.5, and taken it through to production without problem.
You can automate this if you want;
appcmd set config -section:system.applicationHost/applicationPools /applicationPoolDefaults.processModel.setProfileEnvironment:"true" /commit:apphost
or if you prefer powershell
Set-WebConfigurationProperty "/system.applicationHost/applicationPools/applicationPoolDefaults/processModel" -PSPath IIS:\ -Name "setProfileEnvironment" -Value "true"
Hope this helps
I am experiencing the same problem. Have you by chance installed the Visual Studio 11 beta? I did recently, and I've noticed a couple of differences in how the 4.0 compatible .dlls for that work with our code. I'm still trying to track down the problem for certain, but I didn't have this problem before that.
Edit:
After comparing the decompiled sources from 4.0 and 4.5 for GetFolderPath (and related), there are differences. Whether they are the source of the problem...I'm not sure yet.
Edit 2: Here are the relevant changes. I'm working on trying both to see if I get different results. [code removed]
Edit 3:
I've now tried calling SHGetFolderPath directly, which is what the .NET Framework ends up doing, anyway. It returns E_ACCESSDENIED (-2147024891 / 0x80070005). I don't know what has changed where I'm getting that in some specific cases, but not in others.
Edit 4:
Since you're getting a empty string, you may want to switch your code to use SHGetFolderPath so you can get the HResult and at least know what exactly is happening.
void Main() {
Console.WriteLine( GetFolderPath( Environment.SpecialFolder.ApplicationData ) );
}
[System.Runtime.InteropServices.DllImport("shell32.dll")]
static extern int SHGetFolderPath(IntPtr hwndOwner, int nFolder, IntPtr hToken, uint dwFlags, StringBuilder pszPath);
private string GetFolderPath( Environment.SpecialFolder folder ) {
var path = new StringBuilder( 260 );
var hresult = SHGetFolderPath( IntPtr.Zero, (int) folder, IntPtr.Zero, 0, path );
Console.WriteLine( hresult.ToString( "X" ) );
return ( (object) path ).ToString( );
}
The problem is with your IIS settings. The answer is here: Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) returns String.Empty