if I try to test this
if (mydeviceconnection.Devicestream != null)
I get System.NullReferenceException.
Visual studio says:
mydeviceconnection.Devicestream was null.
Devicestream is a NetworkStream part of mydeviceconnection class.
I am trying this test to avoid NullReferenceException. This is already inside a try/catch so can run anyway but I was wondering if is possible to avoid the error.
Related
I want my test to proceed next line after the assert fails. I tried "try catch block" but tests are not failing. Do we have anything that can fix this issue in fluent assertion [https://fluentassertions.com/] or anyways to handle this in code?
Sounds you are searching for AssertionScope of FluentAssertions.
using (new AssertionScope())
{
5.Should().Be(10); // will fail but not throw
DoSomeOtherStuff();
} // assertion will raise exception
All failed asserts will be collected until AssertionScope is disposed.
I am trying to react to suspend events within my Windows Store App. I added the appropriate callback method, but I've run into a problem:
App.Current.Suspending += Current_Suspending;
void Current_Suspending(object sender, Windows.ApplicationModel.SuspendingEventArgs e){}
The problem is that, when I trigger the suspension event in Visual Studio and the callback method is called (I have checked it with a breakpoint), it immediately terminates with an Exception:
session state service failed.
Any suggestions on how to solve this problem?
If you are using Prism as I was this can happen when the SessionStateService chokes on serializing an object. Relevant navigation parameters and anything manually added get serialized at app termination or suspension. In my specific case i had a non-nullable enum that wasn't being set on an object used as a navigation parameter. I used the following to verify the DataContractSerializer wasn't having issues with object.
test.Add("testitem", new WorkflowStep());
MemoryStream sessionData = new MemoryStream();
DataContractSerializer serializer = new DataContractSerializer(typeof(Dictionary<string, object>));
serializer.WriteObject(sessionData, test);
I've created a plugin and registered it using hte registration tool. I've also added a step that is supposed to handle a message of creation of an instance. Sadly, the intended behavior doesn't occur.
My guess is that something inside the plugin crashes but I have no idea on how to debug it. Setting up breakpoints is not going to work agains on-line version, I understand, so I'm not even trying.
For legal and technical reasons, I won't be able to lift over the solution to an on-premise installation, neither. Is guessing my only option?
For server-side (plugins) I'm using ITracingService. For client-side I log everything to console. The downside with the first is that you actually need to crash the execution to get to see anything. The downside with the latter is that plugins sometimes get executed without GUI being invoked at all.
When it comes to heavier projects, I simply set up a WCF web service that I call from the plugin and write to that. That way, on one screen, I'm executing the plugin while on the other, I'm getting a nice log file (or just put the sent information to on the screen).
You could, for instance, start with a very basic update of a field on the instance of your entity that's being created. When you have that working, you can always fall back to the last working version. If you don't even get that to work, it mean, probably, that you're setting up the plugin registration incorrectly.
A very efficient way would be to lift over the solution to an on-premise version where you have full control but I see in your question that it's not en option.
In case you could lift the solution to an on-premise version, here's a link on how to debug plugins.
Don't forget that you also have access to the ITracingService.
You can get a reference to it in your Execute method and then write to it every so often in your code to log variables or courses of action that you are attempting or have succeeded with. You can also use it to surface more valuable information when an exception occurs.
It's basically like writing to a console. Then, if anything causes the plug-in to crash at runtime then you can see everything that you've traced when you click Download Log File on the error shown to the user.
Beware though - unless your plug-in actually throws an exception (deliberate or otherwise) then you have no access to whatever was traced.
Example:
public void Execute(IServiceProvider serviceProvider)
{
// Obtain the execution context from the service provider.
IPluginExecutionContext context =
(IPluginExecutionContext)serviceProvider.GetService(
typeof(IPluginExecutionContext));
// Get a reference to the tracing service.
ITracingService tracingService =
(ITracingService)serviceProvider.GetService(typeof(ITracingService));
try
{
tracingService.Trace("Getting entity from InputParameters...");
// may fail for some messages, since "Target" is not present
var myEntity = (Entity)context.InputParameters["Target"];
tracingService.Trace("Got entity OK");
// some other logic here...
}
catch (FaultException<OrganizationServiceFault> ex)
{
_trace.Trace(ex.ToString());
while (ex.InnerException != null)
{
ex = (FaultException<OrganizationServiceFault>)ex.InnerException;
_trace.Trace(ex.ToString());
}
throw new InvalidPluginExecutionException(
string.Format("An error occurred in your plugin: {0}", ex));
}
catch (Exception ex)
{
_trace.Trace(ex.ToString());
while (ex.InnerException != null)
{
ex = ex.InnerException;
_trace.Trace(ex.ToString());
}
throw;
}
}
I've been having this problem for several days (now fixed and solution noted for anyone that comes across this issue and is pulling their hair out).
After my latest round of code changes to my Silverlight application which uses MVC4 WebAPI for data, I was having a problem with one of my HttpGet Actions which was returning IQueryable<oneofmyclasses>. Using Fiddler2 to watch the request, I could see I was getting an internal server error (500), with no body text to explain why. I received no errors thrown in my Action.
Check 1: I verified that my Action was indeed getting to the return collection.AsQueryable(); line with no errors. It was
Check 2: I verified that my data was serializing to JSON with no errors using this code (g is my collection):
var json = new JsonMediaTypeFormatter();
json.SerializerSettings.PreserveReferencesHandling = PreserveReferencesHandling.Objects;
ObjectContent<IEnumerable<Model.MenuGroup>> responseContent = new ObjectContent<IEnumerable<Model.MenuGroup>>(g, json);
MemoryStream ms = new MemoryStream();
responseContent.CopyToAsync(ms).Wait();
ms.Position = 0;
var sr = new StreamReader(ms);
var str = sr.ReadToEnd();
This also worked. I also tested it using XML formatter even though I was pretty sure it only ever used JSON (can't be too careful).
Check 3: Enabled .Net Framework debugging. This time when the error occured (in HttpApplication.cs) VS 2012 caught it.
My error:
Despite having marked the property with these attributes,
[XmlIgnore]
[IgnoreDataMember]
[JsonIgnore]
the .Net Source was calling a get on one of my properties. The catch, it was a write-only property. I simply added
get { return null; }
and the problem was solved.
I probably should have just done Check 3 first, but my previous experience with this error has shown it to usually be an error trying to serialize my objects, which was why I had a bit of a head scratcher when they did serialize properly and the error persisted.
How I solved it:
Enabled .Net Framework debugging. Tools -> Options -> Debugging -> Check 'Enable .NET Framework source stepping'
This time when the error occured (in HttpApplication.cs) VS 2012 caught it.
I'm using MSTest under Visual Studio 2010 to test an ASP.NET MVC 3 project. I have a SQL Express 2005 DB that I'd like it to use and I want a fresh instance of the DB every time, copied from a template I've included in the project. Pretty standard requirements, I would have though, but I can't get this to work.
I've created a .testsettings file which enables deployment and my connection string looks like this:
<add name="MyDb" connectionString="Data Source=.\SQLEXPRESS2005;Database=MyDbTest;AttachDBFilename=|DataDirectory|MyDbTest.mdf;User Instance=true;Integrated Security=SSPI;" providerName="System.Data.SqlClient" />
The test runs OK the first time, but after that it fails with errors like this:
Test method ... threw exception: System.Data.DataException: An exception occurred while initializing the database. See the InnerException for details. ---> System.Data.EntityException: The underlying provider failed on Open.
---> System.Data.SqlClient.SqlException: Database '...\bin\Debug\MyDbTest.mdf' already exists. Choose a different database name. Cannot attach the file '...\Out\MyDbTest.mdf' as database 'MyDbTest'.
The accepted answer in this MSDN thead says to remove the "Database=" connection string parameter. However, if I do that it fails with this error:
Test method ... threw exception:
System.InvalidOperationException: Unable to complete operation. The supplied SqlConnection does not specify an initial catalog.
How do I get this to work?
So far I've come up with a hack to change the DB name at runtime, at test assembly initialization time. This requires a further hack - using Reflection to enable modifying the configuration at runtime (thanks to David Gardiner).
[TestClass]
public static class TestHelper
{
[AssemblyInitialize]
public static void AssemblyInit(TestContext context)
{
RandomizeDbName();
}
private static void RandomizeDbName()
{
// Get the DB connection string setting
var connStringSetting = ConfigurationManager.ConnectionStrings["TheDbSetting"];
// Hack it using Reflection to make it writeable
var readOnlyField = typeof(ConfigurationElement).GetField("_bReadOnly",
BindingFlags.Instance | BindingFlags.NonPublic);
readOnlyField.SetValue(connStringSetting, false);
// Randomize the DB name, so that SQL Express doesn't complain that it's already in use
connStringSetting.ConnectionString = connStringSetting.ConnectionString.Replace(
"Database=MyTestDb", "Database=MyTestDb_" + new Random().Next());
}
}
Edit: It's actually even a bit worse than this: I'm having to call TestHelper.RandomizeDbName() at the start of every test that requires a fresh DB, otherwise it gets data left over from previous tests.