Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix set-service failing test #4802

Merged
merged 6 commits into from
Sep 15, 2017
Merged

Conversation

SteveL-MSFT
Copy link
Member

@SteveL-MSFT SteveL-MSFT commented Sep 10, 2017

missed -ErrorAction Stop
changed new-service to return error when given unsupported startuptype

Fix #4800
Fix #4803

@iSazonov
Copy link
Collaborator

Blocked by #4803.

missed -ErrorAction Stop
made cmdlet write error when using unsupported startuptype
re-enabled test
@SteveL-MSFT SteveL-MSFT added the Breaking-Change breaking change that may affect users label Sep 11, 2017
@markekraus
Copy link
Contributor

@SteveL-MSFT something should probably be done about Set-Service.Tests.ps1#L25. That will continue to fail on Linux and macOS as the literal will still be parsed even though the IT is being skipped, and Get-Service is unavailable on Linux/macOS.

@SteveL-MSFT
Copy link
Member Author

@markekraus I see. will fix.

fix test so that a script block only runs if It is run
break;
WriteNonTerminatingError(StartupType.ToString(), DisplayName, Name,
new ArgumentException(), "CouldNotNewService",
ServiceResources.UnsupportedStartupType,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is another instance of Assert(((ServiceStartMode)(-1)) == StartupType, "bad StartupType" in Set-Service. It would be the best if all can be fixed here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will fix

@@ -201,4 +201,7 @@
<data name="ComputerAccessDenied" xml:space="preserve">
<value>The command cannot be used to configure the service '{0}' because access to computer '{1}' is denied. Run PowerShell as admin and run your command again.</value>
</data>
<data name="UnsupportedStartupType" xml:space="preserve">
<value>The startup type '{0}' is not supported by New-Service.</value>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

by New-Service needs to be changed since the same applies to set-service as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will fix

@@ -163,8 +166,7 @@ Describe "Set/New-Service cmdlet tests" -Tags "Feature", "RequireAdminOnWindows"
[System.Management.Automation.PSCredential]::new("username",
(ConvertTo-SecureString "PlainTextPassword" -AsPlainText -Force)))
},
# This test case fails due to #4803. Disabled for now.
# @{name = 'badstarttype'; parameter = "StartupType"; value = "System"},
@{name = 'badstarttype'; parameter = "StartupType"; value = "System"},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add "Boot" too?
Should we check valid and invalid values from System.ServiceProcess.ServiceStartMode? If yes it is better refactor the tests. And for Set-Service too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will change

turned redundant code into helper function used by New/Set-Service
added tests for Set-Service and unsupported StartupTypes
@SteveL-MSFT
Copy link
Member Author

@iSazonov @daxian-dbw feedback addressed

/// <returns>
/// If a supported StartupType is provided, funciton returns true, otherwise false.
/// </returns>
internal static bool GetNativeStartupType(ServiceStartMode StartupType, out DWORD dwStartType)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe TryGetNativeStartupType()?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will change

@@ -1684,22 +1682,14 @@ protected override void ProcessRecord()
|| (ServiceStartMode)(-1) != StartupType)
{
DWORD dwStartType = NativeMethods.SERVICE_NO_CHANGE;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do the initialiazation in GetNativeStartupType. So we could remove this and below call by C# 7.0 pattern NativeMethods.GetNativeStartupType(StartupType, out DWORD dwStartType)) .

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can make that change for New-Service, but for Set-Service, I need to use dwStartType on line 1697 so it has to be initialized.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for clafiry. I think we should leave as is.
Closed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In New-Service, dwStartType is also used in line 2045 when calling NativeMethods.CreateServiceW.
It turns out the following code works:

static void Blah ()
{
    if (!int.TryParse("1", out int result))
    {
        Console.WriteLine("Failed");
    }

    Console.WriteLine(result);
}

It would be the best if we can do it in a consistent way in those 2 places.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed

address PR feedback
@@ -1684,22 +1682,14 @@ protected override void ProcessRecord()
|| (ServiceStartMode)(-1) != StartupType)
{
DWORD dwStartType = NativeMethods.SERVICE_NO_CHANGE;
switch (StartupType)
if ((ServiceStartMode)(-1) != StartupType &&
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems (ServiceStartMode)(-1) != StartupType && should be removed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will change, but will need to change some other code to make this work. Seems like -1 shouldn't be needed at all.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, still need -1 which will be treated as equivalent to SERVICE_NO_CHANGE

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By looking at the original code, for New-Service, SERVICE_AUTO_START would be used in case StartupType is -1. So it seems we cannot just use dwStartType = NativeMethods.SERVICE_NO_CHANGE for (ServiceStartMode)(-1)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New-Service defaults to Automatic whereas Set-Service defaults to -1 to indicate no change.

Copy link
Member

@daxian-dbw daxian-dbw Sep 14, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible that the value of StartupType can be set to (-1)?
In the original code, dwStartType will still be SERVICE_AUTO_START even if StartupType is (-1), while it will be SERVICE_NO_CHANGE after the change.

Turns out we can't do [System.ServiceProcess.ServiceStartMode]-1 in PowerShell, so we are good.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll fix it so if it's (-1), it should default to Auto for New-Service

made StartupType(-1) equivalent to Win32 SERVICE_NO_CHANGE and moved to TryGetNativeStartupType
@SteveL-MSFT
Copy link
Member Author

@daxian-dbw feedback addressed

Copy link
Member

@daxian-dbw daxian-dbw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM except for a non-blocking comment.

@@ -1684,22 +1682,14 @@ protected override void ProcessRecord()
|| (ServiceStartMode)(-1) != StartupType)
{
DWORD dwStartType = NativeMethods.SERVICE_NO_CHANGE;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In New-Service, dwStartType is also used in line 2045 when calling NativeMethods.CreateServiceW.
It turns out the following code works:

static void Blah ()
{
    if (!int.TryParse("1", out int result))
    {
        Console.WriteLine("Failed");
    }

    Console.WriteLine(result);
}

It would be the best if we can do it in a consistent way in those 2 places.

@SteveL-MSFT
Copy link
Member Author

@daxian-dbw can you review latest change?

@daxian-dbw
Copy link
Member

daxian-dbw commented Sep 14, 2017

@SteveL-MSFT we cannot pass the value (-1) to -StartupType parameter. The parameter binding will fail because powershell cannot convert -1 to [System.ServiceProcess.ServiceStartMode]. That means StartupType in New-Service can never be -1, so we should be good without the last commit.
That's why I crossed out my original comment :)

@SteveL-MSFT
Copy link
Member Author

@daxian-dbw yeah, I went through the code and for New-Service, StartupType defaults to Auto and can't ever be set to (-1), so I'll revert the last commit.

@SteveL-MSFT
Copy link
Member Author

Last commit was reverted. We should be good to go.

@iSazonov
Copy link
Collaborator

@SteveL-MSFT @daxian-dbw Is the PR ready to merge?

@daxian-dbw
Copy link
Member

daxian-dbw commented Sep 15, 2017

@iSazonov Yes, it's good to go.
BTW, please don't directly use the history commit messages as the description when squashing and merging. Instead, it's better to summarize the changes of the PR.

@iSazonov iSazonov merged commit b723d6b into PowerShell:master Sep 15, 2017
@SteveL-MSFT SteveL-MSFT deleted the set-service-fail branch September 15, 2017 14:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking-Change breaking change that may affect users
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants