Automatically install updates with ClickOnce deployment - c#

I wanted to deploy my project with ClickOnce deployment. But when I did it like that, it was asking in a dialog box at the end user machine:
A new version of XXXX is available. Do you want to download it now?
But my end users don't have a mouse or keyboard. So my intention is: It must take the updates automatically, but it must NOT ask that dialog box at the client side. How do I achieve this by using ClickOnce deployment?

Looks like you can do this by changing some properties in the build.
http://blog.jnericks.com/configuring-msbuild-to-auto-update-clickonce
MinimumRequiredVersion - Tells ClickOnce that when it updates this
application it should update to this version (however this does not
force ClickOnce to perform the update). As you can see we set this
to the same version number that the ApplicationVersion is set to so
that the MinimumRequiredVersion is always the latest version.
UpdateMode=Foreground - Tells ClickOnce to update the application
before it is opened.
UpdateRequired=True - Tells ClickOnce to automatically perform the
update.
No MSBuild scenario:
Right Click your project and select Properties
Go to the "Publish" tab on the bottom left
Click the "Updates..." button to open the Application Updates dialog
Check "The application should check for updates"
Select "Before the application starts"
Check "Specify a minimum required version for this application"
Enter the Publish Version that you can see in the underlying Publish window as the minimum version. Unfortunately, you have to change this every publish. There might be a way for this to be auto, though.
Then publish the application and test it. This was worked fine for me on a local test application.
Edit: looks like some people have been getting the minimum required version to update, might want to look into their solutions.
Edit 2: Image showing where versioning is important:
Also, note I have "Automatically increment revision with each publish" checked. Every time you go into the Properties for the project, that version will be up to date. You'll generally just have to change the "Revision" part of the Version in the "Application Updates" window to match the "Revision" in the Publish tab.

Sure can! As long as it's a network-deployed application, you can easily check for updates using this code. See below:
Private Sub InstallUpdates()
Dim info As UpdateCheckInfo = Nothing
If (ApplicationDeployment.IsNetworkDeployed) Then
Dim AD As ApplicationDeployment = ApplicationDeployment.CurrentDeployment
Try
info = AD.CheckForDetailedUpdate()
Catch dde As DeploymentDownloadException
(You may want to log here)
Return
Catch ioe As InvalidOperationException
(You may want to log here)
Return
End Try
If (info.UpdateAvailable) Then
Try
AD.Update()
Application.Restart()
Catch dde As DeploymentDownloadException
(You may want to log here)
Return
End Try
End If
End If
End Sub
You can enter this snippet and call it in the startup. It works in console applications, Windows Forms applications, but only if you are network deployed! Where you see all my comments about logging is where I was originally using message boxes with prompts, but this is the version that doesn't require any input!

In addition to Gromer's answer, simply install the AutoUpdateProjectsMinimumRequiredClickOnceVersion nuget package in your project. Once you have your project set to check for updates and to use a minimum required version, this will handle making sure the minimum required version always matches your current version (i.e. user's will always be forced to update to the latest version).

Any ClickOnce application based on an .exe file can be silently installed and updated by a custom installer. A custom installer can implement custom user experience during installation, including custom dialog boxes for security and maintenance operations. To perform installation operations, the custom installer uses the InPlaceHostingManager class.
For implementing this solution please refer to this link

I know it's an old Q. but, I will answer anyway. (hope it will help someone):
First, you need to check: Choose when the application should check for updates >> After the application starts.
Secondly, add this method to your code:
private Boolean isVersionOK()
{
UpdateCheckInfo info = null;
if (ApplicationDeployment.IsNetworkDeployed)
{
ApplicationDeployment ad = ApplicationDeployment.CurrentDeployment;
try
{
info = ad.CheckForDetailedUpdate();
}
catch (DeploymentDownloadException)
{
// No network connection
return false;
}
catch (InvalidDeploymentException)
{
return false;
}
catch (InvalidOperationException)
{
return false;
}
if (info.UpdateAvailable)
{
try
{
ad.Update();
Application.Restart();
Environment.Exit(0);
}
catch (DeploymentDownloadException)
{
// No network connection
}
return false;
}
return true;
}
else
{
return false;
}
}
Lastly, you just need to call isVersionOK() at the start of your app and in every few loops as needed to check for update. it will return TRUE if you are on your latest version otherwise it will return FALSE and expect the app will restart to a newer version automatically without user interaction.

In follow-up of Ahmed's answer, below is the code in VB.NET with minor enhancements. It might not be as per the best practices yet it is readable and descriptive.
''' <summary>
''' Checks if the update is available for network based deployment and download it.
''' </summary>
''' <param name="autoDownloadUpdate">If the update is available, should it be downloaded automatically.<para>Default value is <code>True</code></para></param>
''' <returns>It will return <code>True</code> only if the latest version is already installed.
''' <para>If autoDownloadUpdate is set to <code>True</code>, the update is auto downloaded (and app restarts and nothing is returned) else it returns <code>False</code>.</para>
''' </returns>
Shared Private Function CheckAndDownloadUpdate(ByVal Optional autoDownloadUpdate As Boolean = True) As Boolean
If ApplicationDeployment.IsNetworkDeployed = False Then Return False
Dim appDeployment As ApplicationDeployment = ApplicationDeployment.CurrentDeployment
Dim info As UpdateCheckInfo = Nothing
Try
info = appDeployment.CheckForDetailedUpdate
Catch ex As Exception
' Exceptions if you want to handle individually
'DeploymentDownloadException ' No network connection
'InvalidDeploymentException
'InvalidOperationException
Return False
End Try
' If no update is available, it means latest version is installated
If info.UpdateAvailable = False Then Return True
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
' If we are here, it means an update is available on the network
' if autoDownload is False, simply return False
If autoDownloadUpdate = False Then Return False
Try
appDeployment.Update()
Application.Restart()
Environment.Exit(0)
Catch ex As DeploymentDownloadException
' No network connection
Return False
End Try
End Function
An then in your startup code, you can call like this
CheckAndDownloadUpdate()
Any feedback to further ehance the answer...

Related

System.DirectoryServices.AccountManagement.PrincipalContext broken after Windows 10 update

I've been using this little function without any issue for the past few years to validate user credentials. The createPrincipalContext method returns a PrincipalContext with ContextType.Machine and the machine name.
public static bool ValidateCredentials(string username, string password, string domain = null) {
try {
using (var principalContext = createPrincipalContext(username, domain)) {
username = GetLoginInfo(username).Username;
// validate the credentials
if (principalContext.ValidateCredentials(username, password)) {
//once valid check if account is enabled
using (UserPrincipal user = UserPrincipal.FindByIdentity(principalContext, username)) {
return user.Enabled.GetValueOrDefault(false);
}
}
}
} catch (PrincipalOperationException e) {
traceError(e);
} catch (Exception e) {
traceError(e);
}
return false;
}
My development machine automatically updated to the latest version of Windows 10 this recently, and since then, principalContext.ValidateCredentials has been throwing the following exception.
System.IO.FileNotFoundException: The system cannot find the file specified.
Other than the machine update nothing else was changed. I've spend the last few days searching the net for what may have caused the issue.
Does anyone have any experience in identifying what may have been the cause and if possible, a solution?
One final Google before I started rolling back my machine to the previous build and I found this
https://connect.microsoft.com/IE/feedback/details/1904887/windows-10-insider-preview-build-10565
the problem is caused by missing registry entries in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion, specifically: RegisteredOwner and RegisteredOrganization
EDIT:
Run the Registry Editor by pressing Windows R and typing regedit.exe. Browse to the location above
Just right click on the CurrentVersion in the Registry Editor and select New > String Value. After you add each entry ( RegisteredOwner and RegisteredOrganization ) edit their values. You can use your username and company name respectively.
Uncheck the Prefer 32-bit checkbox in your project's properties window under the Build tab, it is checked by default - see screenshot. This fixed it for me! Checking the checkbox again will cause the exceptions you describe to re-appear. I'm guessing this will force it to run in 64-bit mode if possible, and therefore use the 64-bit registry path rather than the WOW6432Node registry path and hence it will find the correct keys it needs.
Uncheck 'Prefer 32-bit' screenshot
Try change your build platform target to "AnyCPU", i found that if my platform target is x86, I have this issue!
Why, yet have no idea, seems like win 10 bug!!!

Check if the current document in Visual Studio 2012 is a Code Window

I am looking for a way to have my extension check if the currently opened window in visual studio 2012 is one, where the user can write code (or any kind of text, really).
To check if the currently opened window has changed, I use
_DTE.Events.WindowEvents.WindowActivated.
This gives me the EnvDTE.Window that received the focus.
When I look at the properties of that window while debugging, and I look at EnvDTE.Window.Document.Type and it's value is "Text".
However, if I stop debugging and try to access the Document.Type property, it does not exist.
If I look for this property in the documentation of EnvDTE.Window.Document, its description says
Infrastructure. Microsoft Internal Use Only.
So now I am looking for any advice on how I could check if the currently active window is one, where I can write code (or anything else), or some other kind of document (like the solution properties for example).
Edit:
I also tried checking Window.Type and Window.Kind of the active window, but they just tell me that it's a document, not making any differentiation between a resource file, an image file or an actual source file, which is what I'm trying to find out.
Edit²:
The reason why I want to check if the current document is one where I can write code in, is because I want my extension to store information about some of those documents and I want to modify the right-click context menu based on the information I have stored, if any.
It is not a "real" answer, but you can follow status of VS GoTo command - it is available only for text editors:
bool isCodeWindow = IsCommandAvailable("Edit.GoTo");
private bool IsCommandAvailable(string commandName)
{
EnvDTE80.Commands2 commands = dte.Commands as EnvDTE80.Commands2;
if (commands == null)
return false;
EnvDTE.Command command = commands.Item(commandName, 0);
if (command == null)
return false;
return command.IsAvailable;
}
You can check to see if the document is a 'TextDocument'
bool isCodeWindow = dte.CurrentDocument.Object() is EnvDTE.TextDocument;

How to determine if user is an Administrator, even if non-elevated

In my C# application, I need to check if the current user is a member of the Administrators group. It needs to be compatible with both Windows XP and Windows 7.
Currently, I am using the following code:
bool IsAdministrator
{
get
{
WindowsIdentity identity = WindowsIdentity.GetCurrent();
WindowsPrincipal principal = new WindowsPrincipal(identity);
return principal.IsInRole(WindowsBuiltInRole.Administrator);
}
}
The problem is that this method returns false if the application is run on Windows 7 with UAC turned on as a non-elevated Administrator. How can I determine if the user is an Administrator even if the application is run as a non-elevated Administrator?
There is a Win32 API GetTokenInformation that can be used to check the current token. If the returned token is a split token, it probably is an administrator user that is running i non elevated mode.
GetTokenInformation has an output parameter tokenInformation which takes one of three values:
TokenElevationTypeDefault = 1
TokenElevationTypeFull = 2
TokenElevationTypeLimited = 3
A value of TokenElevantionTypeLimited indicates that the user is running with a split token with limited privileges. When elevated the TokenElevationTypeFull value is returned. Non-admin user has a value of TokenElevationTypeDefault.
There is a complete code example for C# at http://www.davidmoore.info/2011/06/20/how-to-check-if-the-current-user-is-an-administrator-even-if-uac-is-on/
For any VB.NET people (I know you're out there ...), here's a version that I concocted from various sources and is, I think, optimized to determine whether the current user (including elevated) is in a defined Administrators group, machine or domain, with or without UAC enabled. (Lots of credit to other posts here and elsewhere for this one!)
Firstly, it uses a static null-able Boolean to retain the Administrator status because, although the basic check is quick, the full test can take tens of seconds, so you only want to do it once - if at all if you can help it.
Secondly, it errs on the side of the basic test being incorrect/false, which is usually the case if the user is AD-administered or if the local machine has UAC enabled. So if it can decide a user is an Administrator, it will.
Thirdly, you can add or remove criteria from the AuthorizationGroups as you see fit but the ones included cover most situations.
Lastly, if anything goes wrong, you'll get False; if you want an error, you can have one, but personally I don't see the point.
Function IsAdministrator() As Boolean
Static bResult As Boolean? = Nothing
Try
If bResult Is Nothing Then
bResult = New WindowsPrincipal(WindowsIdentity.GetCurrent()).IsInRole(WindowsBuiltInRole.Administrator)
If Not bResult Then
Dim oContext As PrincipalContext = Nothing
Try 'to get a domain context first ...
Domain.GetComputerDomain()
oContext = New PrincipalContext(ContextType.Domain)
Catch
'... if it fails, fall through to a machine context
End Try
If oContext Is Nothing Then oContext = New PrincipalContext(ContextType.Machine)
Dim oPrincipal As UserPrincipal = UserPrincipal.FindByIdentity(oContext, WindowsIdentity.GetCurrent().Name)
If oPrincipal IsNot Nothing Then
bResult = oPrincipal.GetAuthorizationGroups().Any(Function(p) _
p.Sid.IsWellKnown(WellKnownSidType.BuiltinAdministratorsSid) OrElse
p.Sid.IsWellKnown(WellKnownSidType.AccountDomainAdminsSid) OrElse
p.Sid.IsWellKnown(WellKnownSidType.AccountAdministratorSid) OrElse
p.Sid.IsWellKnown(WellKnownSidType.AccountEnterpriseAdminsSid))
End If
End If
End If
Catch
bResult = False
End Try
Return bResult.GetValueOrDefault(False)
End Function
I know this is old but I've found the below way to work well across all systems. I needed it to work on .net 2 and other solutions such as WinAPI and Management Objects failed on certain versions of Windows:
Launch a new process running the command net localgroup administrators and parse the output appropriately. This works with both UAC enabled and disabled and doesn't need an elevated process.
If you are an Admin, you could temporarily disable UAC from code then re-enable it. The registry key is
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Value: EnableLUA
Set to: 0 to disable, 1 to enable
So you could do something like
RegistryKey myKey = Registry.LocalMachine.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\Policies\\System", true);
myKey.SetValue("EnableLUA", "1", RegistryValueKind.String);
Then check your principal.. It is kindof a hack, but its worth a shot.

Webbrowser control ignores FEATURE_BROWSER_EMULATION reg entry

Im developing a custom browser solution with .net's Webbrowser control.
To disable the IE-Compatibilty View, I set the registry entry
Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION:
[Sreenshot regedit] http://zbirk.mirk.at/browserreg.png "Screenshot"
i tried to use the values: dword=8000,dword=8888,dword=9000, but the webbrowser control seems to ignore these reg entries.
Maybe someone had this problems too and may help me.
The WebBrowser control definately DOES respect these keys.
Remember that while taskman may show application.exe in the name column, if you are debugging the exe name is application.vshost.exe
So in my application sI just attempt to create the key every time the app runs. If it fails to create it (because it already exists) then I continue running, if it creates the key then I inform the user that they need to restart the application.
ensure that you are not running within vshost
the app name would be different ie appname.vshost.exe
Thx for your reply, now its working.
Her is my working peace of code:
public void setIEcomp()
{
String appname = Process.GetCurrentProcess().ProcessName+".exe";
RegistryKey RK8 = Registry.LocalMachine.OpenSubKey("Software\\Microsoft\\Internet Explorer\\Main\\FeatureControl\\FEATURE_BROWSER_EMULATION",RegistryKeyPermissionCheck.ReadWriteSubTree);
int value9 = 9999;
int value8 = 8888;
Version ver = webBrowser1.Version;
int value = value9;
try
{
string[] parts = ver.ToString().Split('.');
int vn = 0;
int.TryParse(parts[0], out vn);
if (vn != 0)
{
if (vn == 9)
value = value9;
else
value = value8;
}
}
catch
{
value = value9;
}
//Setting the key in LocalMachine
if (RK8 != null)
{
try
{
RK8.SetValue(appname, value, RegistryValueKind.DWord);
RK8.Close();
}
catch(Exception ex)
{
//MessageBox.Show(ex.Message);
}
}
}
I too could not see that FEATURE_BROWSER_EMULATION made any difference in my application.
I was testing the FEATURE_BROWSER_EMULATION functionality by manually editing the registry with regedit. Nothing I did made any difference. My hosted page was still failing on any new-ish JavaScript and could not load external libraries.
I found my mistake:
I was editing the 64-bit view of the registry with regedit. My app was running as a 32-bit app and looking at the 32-bit view of the registry. That's why my changes to the registry seemed to have no impact on my application. By the way, the WPF project template defaults to "Prefer 32-bit."
Manually editing with regedit within the Wow6432Node key worked:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
Of course, setting the DWORD value programmatically within your application will also work, since your 32-bit application will edit within the Wow6432Node.
An older post and solution is no longer accurate.
Running procmon and watching for FEATURE_BROWSER_EMULATION shows the following registry variables actually checked. This was for WINWORD.exe but other than that - take your pick...
HKU\S-1-5-21-[my-sid-paws-off]\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION\WINWORD.EXE
HKU\S-1-5-21-[my-sid-paws-off]\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION*
HKLM\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION(Default)
HKLM\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION\WINWORD.EXE
HKLM\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION\WINWORD.EXE
HKLM\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION*
HKLM\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION*

Uninstalling my Office 2010 plugin leaves a null pointer exception

I've been trying to track down why my Office2010 plugin leaves a null pointer exception during uninstall and the 2007 version does not. (Edit: 2007 is at same state as 2010 - FAIL)
To narrow it down I have put in a couple of eventlog traps, meaning if code reaches this point - I should get something in the Eventlog. No such luck. Now either I written the eventlog trap wrong or code doesn't reach that point.
In the CustomSetupActions - ClickOnceInstaller.cs
public void Uninstall(System.Collections.IDictionary savedState)
{
// write something to eventlog
// This is not being fired, the exception doesn't reach here or writing to eventlog fails.
if (!EventLog.SourceExists("OfficePlugin"))
{
EventLog.CreateEventSource("OfficePlugin", "Application");
}
EventLog.WriteEntry
("OfficePlugin"
, string.Format("Uninstalling: (bug hunting)"), EventLogEntryType.Information);
string deploymentLocation = (string)savedState["deploymentLocation"];
if (deploymentLocation != null)
{
string arguments = String.Format(
"/S /U \"{0}\"", deploymentLocation);
ExecuteVSTOInstaller(arguments);
}
}
As for the ExecuteVSTOInstaller(string arguments)
2007 refers to: string subPath = #"Microsoft Shared\VSTO\9.0\VSTOInstaller.exe";
2010 refers to: string subPath = #"Microsoft Shared\VSTO\10.0\VSTOInstaller.exe";
If the first trap had fired, this is where I would have placed the trap afterwards.
--
I have another method that handles the registration db
RegisterOffice2010AddIn.cs
public void UnRegisterAddIn(string applicationName, string addInName)
{
Next line is precisely the same eventlog trap as I just used/shown.
Difference between the two (2007 vs 2010).
private const string UserSettingsLocation =
#"Software\Microsoft\Office\12.0\User Settings";
vs
private const string UserSettingsLocation =
#"Software\Microsoft\Office\14.0\User Settings";
I can't think of any other place that might be interesting to place the trap. I have a CustomInstaller which doesn't do anything besides Dispose(bool disposing) and InitializeComponent()
Development:
Action start 14:21:00: PublishFeatures.
Action ended 14:21:00: PublishFeatures. Return value 1.
Action start 14:21:00: PublishProduct.
Action ended 14:21:00: PublishProduct. Return value 1.
Action start 14:21:00: InstallExecute.
MSI (c) (B8:BC) [14:21:01:013]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
Error 1001. Error 1001. An exception occurred while uninstalling. This exception will be ignored and the uninstall will continue. However, the application might not be fully uninstalled after the uninstall is complete. --> Object reference not set to an instance of an object.
DEBUG: Error 2769: Custom Action _EE8A0D36_BE55_421F_9A55_95470C001D87.uninstall did not close 1 MSIHANDLEs.
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: _EE8A0D36_BE55_421F_9A55_95470C001D87.uninstall, 1,
Action ended 14:21:05: InstallExecute. Return value 3.
Action ended 14:21:06: INSTALL. Return value 3.
Googling the Error 2769 - gives an answer of "[TARGETDIR]\" , but I dont reference TargetDir, I reference deploymentLocation. And Yes I have tried adding the "\" to places I could think of. Including the setup - Registry - HKLM\Software\MS\Office\12.0\ ...etc... \Addins\Excel/Word/Outlook and the Manifest keyvalue. Gave no feedback, good or bad, errors or otherwise. I'm at a loss what else to try to hunt this one down.
I have a guess it is referencing to this, in the VDPROJ:
{
"Name" = "8:UnregisterOutlookAddIn"
"Condition" = "8:"
"Object" = "8:_73E71A44EB72485AB7367745F7D57F49"
"FileType" = "3:1"
"InstallAction" = "3:4"
"Arguments" = "8:"
"EntryPoint" = "8:"
"Sequence" = "3:3"
"Identifier" = "8:_EE8A0D36_BE55_421F_9A55_95470C001D87"
"InstallerClass" = "11:TRUE"
"CustomActionData" = "8:/addinName=\"OUR.Outlook.Outlook2010AddIn\" /application=\"Outlook\""
}
I found it throws two exception - the secondary under CustomSetupActions and UnregisterAddIn and the primary under ClickOnceInstaller and Uninstall. Howcome I mention them as 2ndary and primary. Well it will do the exception in CustomAction and then the killing one in ClickOnce. I've eliminated the one in CustomActions and I now only have to worry about the ClickOnce. From what I can gather the ClickOnce implements the interface specified in the Setup Project (Install, Rollback, Commit, Uninstall). I only have to figure out how it can run amiss the Uninstall method.
Disclaimer: Unless ofcourse I'm mistaken and is barking up the wrong tree.
Change to WiX. It became a workaround as the original is still true.

Categories

Resources