ServiceStack Selfhosted Application Restart - c#

How can I restart a ServiceStack self hosted Apphost? Setting my AppHost instance to null and disposing of it does not work correctly, it throws the following Exception:
System.ArgumentException: An entry with the same key already exists.
I need to be able to do this to reload settings and start the AppHost without restarting the Windows Service hosting the AppHost
EDIT:
Scott and Moo-Juice's suggestions to run the AppHost in a different AppDomain is the correct solution. In order to get past the Cross Domain calls to restart the AppHost, I created a second AppHost which runs in the Main AppDomain and calls the Restart method from Scott's solution. Enabling CORS on both AppHost instances allows for a simple $ajax call to restart the service and reload the page once the service is started and the request returns.

Use an AppDomain:
Moo-Juice's suggestion to use an AppDomain is correct. I have included a simple example of how to use an AppDomain to isolate ServiceStack, and allow it to be Started/Restarted/Stopped.
using System;
using ServiceStack;
using System.Runtime.Remoting;
namespace Test
{
public class ServiceStackConsoleHost : MarshalByRefObject
{
public static void Main()
{
Start();
}
static ObjectHandle Handle;
static AppDomain ServiceStackAppDomain;
public static void Start()
{
// Get the assembly of our host
var assemblyName = typeof(ServiceStackConsoleHost).Assembly.FullName;
// Create an AppDomain
ServiceStackAppDomain = AppDomain.CreateDomain("ServiceStackAppDomain");
// Load in our service assembly
ServiceStackAppDomain.Load(assemblyName);
// Create instance of our ServiceStack application
Handle = ServiceStackAppDomain.CreateInstance(assemblyName, "Test.ServiceStackConsoleHost");
// Show that the main application is in a separate AppDomain
Console.WriteLine("Main Application is running in AppDomain '{0}'", AppDomain.CurrentDomain.FriendlyName);
// Wait for input
Console.ReadLine();
// Restart the application
Restart();
}
public static void Stop()
{
if(ServiceStackAppDomain == null)
return;
// Notify ServiceStack that the AppDomain is going to be unloaded
var host = (ServiceStackConsoleHost)Handle.Unwrap();
host.Shutdown();
// Shutdown the ServiceStack application
AppDomain.Unload(ServiceStackAppDomain);
ServiceStackAppDomain = null;
}
public static void Restart()
{
Stop();
Console.WriteLine("Restarting ...");
Start();
}
readonly AppHost appHost;
public ServiceStackConsoleHost()
{
appHost = new AppHost();
appHost.Init();
appHost.Start("http://*:8090/");
Console.WriteLine("ServiceStack is running in AppDomain '{0}'", AppDomain.CurrentDomain.FriendlyName);
}
public void Shutdown()
{
if(appHost != null)
{
Console.WriteLine("Shutting down ServiceStack host");
if(appHost.HasStarted)
appHost.Stop();
appHost.Dispose();
}
}
}
public class AppHost : AppSelfHostBase
{
public AppHost(): base("My ServiceStack Service", typeof(AppHost).Assembly)
{
}
public override void Configure(Funq.Container container)
{
}
}
}
Instructions for how to use an AppDomain can be found here.

Related

how to make a c# program run in background and at startup [duplicate]

I have console application and would like to run it as Windows service. VS2010 has project template which allow to attach console project and build Windows service.
I would like to not add separated service project and if possible integrate service code into console application to keep console application as one project which could run as console application or as windows service if run for example from command line using switches.
Maybe someone could suggest class library or code snippet which could quickly and easily transform c# console application to service?
I usually use the following techinque to run the same app as a console application or as a service:
using System.ServiceProcess
public static class Program
{
#region Nested classes to support running as service
public const string ServiceName = "MyService";
public class Service : ServiceBase
{
public Service()
{
ServiceName = Program.ServiceName;
}
protected override void OnStart(string[] args)
{
Program.Start(args);
}
protected override void OnStop()
{
Program.Stop();
}
}
#endregion
static void Main(string[] args)
{
if (!Environment.UserInteractive)
// running as service
using (var service = new Service())
ServiceBase.Run(service);
else
{
// running as console app
Start(args);
Console.WriteLine("Press any key to stop...");
Console.ReadKey(true);
Stop();
}
}
private static void Start(string[] args)
{
// onstart code here
}
private static void Stop()
{
// onstop code here
}
}
Environment.UserInteractive is normally true for console app and false for a service. Techically, it is possible to run a service in user-interactive mode, so you could check a command-line switch instead.
I've had great success with TopShelf.
TopShelf is a Nuget package designed to make it easy to create .NET Windows apps that can run as console apps or as Windows Services. You can quickly hook up events such as your service Start and Stop events, configure using code e.g. to set the account it runs as, configure dependencies on other services, and configure how it recovers from errors.
From the Package Manager Console (Nuget):
Install-Package Topshelf
Refer to the code samples to get started.
Example:
HostFactory.Run(x =>
{
x.Service<TownCrier>(s =>
{
s.ConstructUsing(name=> new TownCrier());
s.WhenStarted(tc => tc.Start());
s.WhenStopped(tc => tc.Stop());
});
x.RunAsLocalSystem();
x.SetDescription("Sample Topshelf Host");
x.SetDisplayName("Stuff");
x.SetServiceName("stuff");
});
TopShelf also takes care of service installation, which can save a lot of time and removes boilerplate code from your solution. To install your .exe as a service you just execute the following from the command prompt:
myservice.exe install -servicename "MyService" -displayname "My Service" -description "This is my service."
You don't need to hook up a ServiceInstaller and all that - TopShelf does it all for you.
So here's the complete walkthrough:
Create new Console Application project (e.g. MyService)
Add two library references: System.ServiceProcess and System.Configuration.Install
Add the three files printed below
Build the project and run "InstallUtil.exe c:\path\to\MyService.exe"
Now you should see MyService on the service list (run services.msc)
*InstallUtil.exe can be usually found here: C:\windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.ex‌​e
Program.cs
using System;
using System.IO;
using System.ServiceProcess;
namespace MyService
{
class Program
{
public const string ServiceName = "MyService";
static void Main(string[] args)
{
if (Environment.UserInteractive)
{
// running as console app
Start(args);
Console.WriteLine("Press any key to stop...");
Console.ReadKey(true);
Stop();
}
else
{
// running as service
using (var service = new Service())
{
ServiceBase.Run(service);
}
}
}
public static void Start(string[] args)
{
File.AppendAllText(#"c:\temp\MyService.txt", String.Format("{0} started{1}", DateTime.Now, Environment.NewLine));
}
public static void Stop()
{
File.AppendAllText(#"c:\temp\MyService.txt", String.Format("{0} stopped{1}", DateTime.Now, Environment.NewLine));
}
}
}
MyService.cs
using System.ServiceProcess;
namespace MyService
{
class Service : ServiceBase
{
public Service()
{
ServiceName = Program.ServiceName;
}
protected override void OnStart(string[] args)
{
Program.Start(args);
}
protected override void OnStop()
{
Program.Stop();
}
}
}
MyServiceInstaller.cs
using System.ComponentModel;
using System.Configuration.Install;
using System.ServiceProcess;
namespace MyService
{
[RunInstaller(true)]
public class MyServiceInstaller : Installer
{
public MyServiceInstaller()
{
var spi = new ServiceProcessInstaller();
var si = new ServiceInstaller();
spi.Account = ServiceAccount.LocalSystem;
spi.Username = null;
spi.Password = null;
si.DisplayName = Program.ServiceName;
si.ServiceName = Program.ServiceName;
si.StartType = ServiceStartMode.Automatic;
Installers.Add(spi);
Installers.Add(si);
}
}
}
Here is a newer way of how to turn a Console Application to a Windows Service as a Worker Service based on the latest .NET 6.
In Visual Studio 2022 you have out of the box Worker Service as a project template.
This gives you a main method and a Worker.cs on which you need a few more lines
Worker.cs on which I've added the StartAsync and StopAsync overrides to chose what my service does at start/stop.
namespace WorkerService
{
public class Worker : BackgroundService
{
private readonly ILogger<Worker> _logger;
public Worker(ILogger<Worker> logger)
{
_logger = logger;
}
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
//do some operation
}
public override Task StartAsync(CancellationToken cancellationToken)
{
return base.StartAsync(cancellationToken);
}
public override Task StopAsync(CancellationToken cancellationToken)
{
return base.StopAsync(cancellationToken);
}
}
}
and Program.cs on which you will need to add .UseWindowsService()
using WorkerService;
IHost host = Host.CreateDefaultBuilder(args)
.ConfigureServices(services =>
{
services.AddHostedService<Worker>();
})
.UseWindowsService()
.Build();
await host.RunAsync();
And you will need to install the following NuGet for this method
Install-Package Microsoft.Extensions.Hosting.WindowsServices
Old answer -> .NET Core 3.1
If you create a Worker Service from Visual Studio 2019 it will give you almost everything you need for creating a Windows Service out of the box, which is also what you need to change to the console application in order to convert it to a Windows Service.
Here are the changes you need to do:
Install the following NuGet packages
Install-Package Microsoft.Extensions.Hosting.WindowsServices -Version 3.1.0
Install-Package Microsoft.Extensions.Configuration.Abstractions -Version 3.1.0
Change Program.cs to have an implementation like below:
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
namespace ConsoleApp
{
class Program
{
public static void Main(string[] args)
{
CreateHostBuilder(args).UseWindowsService().Build().Run();
}
private static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureServices((hostContext, services) =>
{
services.AddHostedService<Worker>();
});
}
}
and add Worker.cs where you will put the code which will be run by the service operations:
using Microsoft.Extensions.Hosting;
using System.Threading;
using System.Threading.Tasks;
namespace ConsoleApp
{
public class Worker : BackgroundService
{
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
//do some operation
}
public override Task StartAsync(CancellationToken cancellationToken)
{
return base.StartAsync(cancellationToken);
}
public override Task StopAsync(CancellationToken cancellationToken)
{
return base.StopAsync(cancellationToken);
}
}
}
Installing the app as a Windows Service
When everything is ready, and the application has built successfully, you can use sc.exe to install your console application exe as a Windows Service with the following command:
sc.exe create DemoService binpath= "path/to/your/file.exe"
Firstly I embed the console application solution into the windows service solution and reference it.
Then I make the console application Program class public
/// <summary>
/// Hybrid service/console application
/// </summary>
public class Program
{
}
I then create two functions within the console application
/// <summary>
/// Used to start as a service
/// </summary>
public void Start()
{
Main();
}
/// <summary>
/// Used to stop the service
/// </summary>
public void Stop()
{
if (Application.MessageLoop)
Application.Exit(); //windows app
else
Environment.Exit(1); //console app
}
Then within the windows service itself I instantiate the Program and call the Start and Stop functions added within the OnStart and OnStop. See below
class WinService : ServiceBase
{
readonly Program _application = new Program();
/// <summary>
/// The main entry point for the application.
/// </summary>
static void Main()
{
ServiceBase[] servicesToRun = { new WinService() };
Run(servicesToRun);
}
/// <summary>
/// Set things in motion so your service can do its work.
/// </summary>
protected override void OnStart(string[] args)
{
Thread thread = new Thread(() => _application.Start());
thread.Start();
}
/// <summary>
/// Stop this service.
/// </summary>
protected override void OnStop()
{
Thread thread = new Thread(() => _application.Stop());
thread.Start();
}
}
This approach can also be used for a windows application / windows service hybrid
I hear your point at wanting one assembly to stop repeated code but, It would be simplest and reduce code repetition and make it easier to reuse your code in other ways in future if...... you to break it into 3 assemblies.
One library assembly that does all the work.
Then have two very very slim/simple projects:
one which is the commandline
one which is the windows service.
You can use
reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run /v ServiceName /d "c:\path\to\service\file\exe"
And it will appear int the service list. I do not know, whether that works correctly though. A service usually has to listen to several events.
There are several service wrapper though, that can run any application as a real service. For Example Microsofts SrvAny from the Win2003 Resource Kit
Maybe you should define what you need, as far as I know, you can't run your app as Console or Service with command line, at the same time. Remember that the service is installed and you have to start it in Services Manager, you can create a new application wich starts the service or starts a new process running your console app. But as you wrote
"keep console application as one project"
Once, I was in your position, turning a console application into a service. First you need the template, in case you are working with VS Express Edition. Here is a link where you can have your first steps: C# Windows Service, this was very helpful for me. Then using that template, add your code to the desired events of the service.
To improve you service, there's another thing you can do, but this is not quick and/or easily, is using appdomains, and creating dlls to load/unload. In one you can start a new process with the console app, and in another dll you can just put the functionality the service has to do.
Good luck.
You need to seperate the functionality into a class or classes and launch that via one of two stubs. The console stub or service stub.
As its plain to see, when running windows, the myriad services that make up the infrastructure do not (and can't directly) present console windows to the user. The service needs to communicate with the user in a non graphical way: via the SCM; in the event log, to some log file etc. The service will also need to communicate with windows via the SCM, otherwise it will get shutdown.
It would obviously be acceptable to have some console app that can communicate with the service but the service needs to run independently without a requirement for GUI interaction.
The Console stub can very useful for debugging service behaviour but should not be used in a "productionized" environment which, after all, is the purpose of creating a service.
I haven't read it fully but this article seems to pint in the right direction.
I use a service class that follows the standard pattern prescribed by ServiceBase, and tack on helpers to easy F5 debugging. This keeps service data defined within the service, making them easy to find and their lifetimes easy to manage.
I normally create a Windows application with the structure below. I don't create a console application; that way I don't get a big black box popping in my face every time I run the app. I stay in in the debugger where all the action is. I use Debug.WriteLine so that the messages go to the output window, which docks nicely and stays visible after the app terminates.
I usually don't bother add debug code for stopping; I just use the debugger instead. If I do need to debug stopping, I make the project a console app, add a Stop forwarder method, and call it after a call to Console.ReadKey.
public class Service : ServiceBase
{
protected override void OnStart(string[] args)
{
// Start logic here.
}
protected override void OnStop()
{
// Stop logic here.
}
static void Main(string[] args)
{
using (var service = new Service()) {
if (Environment.UserInteractive) {
service.Start();
Thread.Sleep(Timeout.Infinite);
} else
Run(service);
}
}
public void Start() => OnStart(null);
}

Different AppDomain Corrupted State Exception (AccessViolationException) Application Pool Worker Process

How can I prevent an entire application (process) crash when AccessViolationException (or another Corrupted State Exception) is thrown in an AppDomain in .NET 4.6? My goal is to wrap a 3rd party library (GdPicture.NET barcode reader) in its AppDomain, which intermittently crashes IIS worker process according to IIS crash dumps. In other words, I'd like to isolate 3rd party library call in its own app domain so that it can fail within itself without taking the entire web site down.
In the sample code below, if I don't use HandleProcessCorruptedStateExceptions attribute I cannot catch the AccessViolationException (wrapped in TargetInvocationException) which is thrown in a different AppDomain (in ClassLibrary1.dll). If I decorate HandleProcessCorruptedStateExceptions (for only the 2nd AppDomain call), is it safe for the main process to continue or does it become to an unstable state?
Visual Studio solution with two projects (a console app and a class library).
using System;
using System.Reflection;
using System.Runtime.ExceptionServices;
using System.Security;
namespace StackOverflowQuestion
{
class Program
{
static void Main(string[] args)
{
new Tester().RunTest();
}
}
class Tester
{
public void RunTest()
{
var myTestAppDomain = AppDomain.CreateDomain("My Test AppDomain");
var loader = (Loader)myTestAppDomain.CreateInstanceAndUnwrap(typeof(Loader).Assembly.FullName, typeof(Loader).FullName);
TestHandleProcessCorruptedStateExceptions(loader, myTestAppDomain);
// how can I make sure process doesn't crash when AppDomain "My Test AppDomain" crashes
Console.WriteLine("This won't be written to console unless [HandleProcessCorruptedStateExceptions] attribute is present...");
// keep console window open
Console.ReadKey();
}
// [HandleProcessCorruptedStateExceptions, SecurityCritical]
private void TestHandleProcessCorruptedStateExceptions(Loader loader, AppDomain appDomain)
{
Console.WriteLine("Loading 3rd party lib ClassLibrary1.dll...");
loader.LoadAssembly(#"..\..\..\ClassLibrary1\bin\debug\ClassLibrary1.dll");
try
{
// executing static method in dummy 3rd party dll in a different app domain (named "My Test AppDomain")
loader.ExecuteStaticMethod("ClassLibrary1.Class1", "DoStuff", DateTime.Now.ToShortDateString() + " " + DateTime.Now.ToLongTimeString());
}
catch (TargetInvocationException)
{
AppDomain.Unload(appDomain);
Console.WriteLine("DoStuff failed. This won't be written to console unless [HandleProcessCorruptedStateExceptions] attribute is present...");
}
}
}
class Loader : MarshalByRefObject
{
private Assembly _assembly;
public void LoadAssembly(string path)
{
_assembly = Assembly.Load(AssemblyName.GetAssemblyName(path));
}
public object ExecuteStaticMethod(string typeName, string methodName, params object[] parameters)
{
var type = _assembly.GetType(typeName);
// assume there is no overloads for simplicity
var method = type.GetMethod(methodName, BindingFlags.Static | BindingFlags.Public);
return method.Invoke(null, parameters);
}
}
}
And this is the code in Class1.cs in ClassLibrary1 project:
using System;
using System.Runtime.InteropServices;
namespace ClassLibrary1
{
public class Class1
{
public static void DoStuff(string msg)
{
Console.WriteLine("Throwing AccessViolationException now...");
// throw an AccessViolationException which cannot be caught in a try/catch block
FakeAccessViolationException();
Console.WriteLine("Class1.DoStuff: " + msg);
}
private static void FakeAccessViolationException()
{
var ptr = new IntPtr(42);
Marshal.StructureToPtr(42, ptr, true);
}
}
}

Using dbcontext in .net core application

I am running .net core application as windows services. So my question is how can I use the dbcontext in windows service for database operations?
Below is Service Class
public class SendMailHostService : WebHostService
{
private readonly EventLog _log = new EventLog("Application") { Source = "Application" };
public SendMailHostService(IWebHost host) : base(host)
{
}
protected override void OnStarted()
{
Console.WriteLine("Asp.net service started.");
Console.ReadLine();
}
protected override void OnStarting(string[] args)
{
Console.WriteLine("Asp.net service starting.");
Console.ReadLine();
}
}
and service extension class:
public static class SendMailHostServiceExtensions
{
public static void RunAsSendMailService(this IWebHost host)
{
var webHostService = new SendMailHostService(host);
webHostService.ServiceName = "LMS.WinService.SendEmail";
ServiceBase.Run(webHostService);
}
}
Do I need to inject the dependency in service class?
Edit:1
Initially I need to connect to Client management database in which a table called Clientsconnectionstring will have the connection string of all clients and after that I need to create db context for each of clients and execute windows service logic.
You can create the context on demand in each method you need it.

Start WPF app from unit test in its own AppDomain

I am trying to run a WPF App from nunit. Since I only can run one App per AppDomain I instantiate a new AppDomain per acceptance test. When I do that, I run into serialization exceptions.
namespace Tests
{
[TestFixture, RequiresSTA, Serializable]
public class ApplicationTests
{
private MainWindow mainWindow;
private bool guiVisible;
private App app;
[TestCase("app domain name for instance of App")]
[TestCase("app domain name for another instance of App")]
public void ApplicationTest(string name)
{
AppDomain appDomain = AppDomain.CreateDomain(name);
//appDomain.ExecuteAssembly(#"C:\Users\bp\Documents\Visual Studio 2013\Projects\WpfApplication1\WpfApplication1\bin\Debug\WpfApplication1.exe");
CrossAppDomainDelegate action = () =>
{
app = new App();
app.InitializeComponent();
app.Dispatcher.BeginInvoke(DispatcherPriority.Loaded, new Action(() => AppOnActivated(null, null)));
app.Run();
};
appDomain.DoCallBack(action);
}
private void AppOnActivated(object sender, EventArgs eventArgs)
{
if (!guiVisible)
{
mainWindow = (MainWindow)Application.Current.MainWindow;
mainWindow.ButtonViewModel = new ButtonViewModel();
mainWindow.ButtonViewModel.Name = "bla";
guiVisible = true;
}
app.Shutdown();
}
}
}
The exception I receive now:
System.Runtime.Serialization.SerializationException : Type is not
resolved for member 'Tests.ApplicationTests,Tests, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null'.
I made the test class [Serializable] which does not help either.
Help is very much appreciated. I just want to start my WPF application from an NUnit test so that I can write acceptance tests for my application. I keep running into different walls and eventually whatever path I choose seems to lead to a dead end...
Many thanks in advance,
Bas
AppDomains are software-isolated processes in .NET. This means you can't just reference objects belonging to one AppDomain from another. Objects can be either copied by value (serialization) or by reference using MarshalByRefObject. Since WPF's objects are neither of those, you can't move them around AppDomains.
For your your testing purposes, you could use a simpler approach: run everything within the new AppDomain, and use the SetData and GetData methods to transfer data to assert on.
[TestCase("app domain name for instance of App")]
[TestCase("app domain name for another instance of App")]
public void ApplicationTest(string name)
{
AppDomain appDomain = AppDomain.CreateDomain(name,
AppDomain.CurrentDomain.Evidence,
AppDomain.CurrentDomain.SetupInformation);
appDomain.DoCallBack(StartApp);
Assert.IsTrue((bool)appDomain.GetData("GuiVisible"));
AppDomain.Unload(appDomain);
}
// using a static method instead of a lambda makes sure
// you haven't captured anything
private static void StartApp()
{
app = new App();
app.InitializeComponent();
app.Dispatcher.BeginInvoke(DispatcherPriority.Loaded,
new Action(() => AppOnActivated()));
app.Run();
}
private static void AppOnActivated()
{
var mainWindow = (MainWindow)Application.Current.MainWindow;
mainWindow.ButtonViewModel = new ButtonViewModel();
mainWindow.ButtonViewModel.Name = "bla";
AppDomain.CurrentDomain.SetValue("GuiVisible") = true;
app.Shutdown();
}

scenario background- launch wcf service

I'm testing a WCF service methods using specflow and nunit; my scenarios look like the following:
Feature: GetAccount
Testing API method 'get account'
Background:
Given Server is running
Scenario: Succesful Get
Given An Existing Account
When I call the GetAccount API method With password = "123"
Then the result should be Success
I'm not sure on how to implement the background step;
The server can be run as console / windows service using Topshelf-
private static void Main()
{
Host host = HostFactory.New(config =>
{
config.Service<ServiceInitializer>(service =>
{
service.ConstructUsing(s => new ServiceInitializer());
service.WhenStarted((s, control) => s.Start(control));
service.WhenStopped((s, control) => s.Stop(control));
});
config.RunAsPrompt();
});
host.Run();
}
public class ServiceInitializer : ServiceControl
{
private readonly ILog m_log;
public ServiceInitializer()
{
log4net.Config.XmlConfigurator.Configure();
m_log = LogManager.GetLogger("Server");
}
public bool Start(HostControl hostControl)
{
try
{
var host = new IoCServiceHost(typeof(MyService));
host.Open();
m_log.Info("Server is now open.");
return true;
}
catch (Exception exception)
{
m_log.Fatal("Initialization of service failed",exception);
return false;
}
}
public bool Stop(HostControl hostControl)
{
m_log.Info("Server has closed");
return true;
}
}
should I just execute the .exe service file, or can I use my ServiceInitializer in some way? perhaps I could use nUnit's [SetUpFixture]?
Are there any Specflow best practices?
Let's consider what you want to test.
Do you need to test that Windows correctly runs services?
Do you need to test that Topshelf correctly starts services?
Or do you just want to test that GetAccount works?
I'll bet that you are using Topshelf to make your life easier, so do that and trust that their code works within windows. Its a valid assumption since there code will be used in many places and they probably have their own test suites, and if your assumption is wrong, then test it later when you find the problems.
So all you really need is
[BeforeFeature]
public void Background()
{
FeatureContext.Current["Host"] =new MyHostObject();
}
[When("I call GetAccount API method with password =\"(\.*)\"")]
public void WhenICallGetAccount(string password)
{
var host = (MyHostObject)FeatureContext.Current["Host"];
ScenarioContext.Current["Account"] = host.GetAccount(password);
}
[Then("the result should be success")]
public void ThenTheResultShouldBeSuccessful()
{
var account = (MyAccount)ScenarioContext.Current["Account"];
//assuming using Should;
account.ShouldNotBeNull();
}

Categories