Why C#8 Default implementations of interface members will report an error?
public interface Logger
{
void Info(string message);
void Error(string message);
// C#8 Default implementations of interface
void Warn(string message)
{
// "interface method cannot declare a body" error message
}
}
and
.NET Core 3.0 is configured as shown in the screenshot.
This is a Resharper/Rider bug: https://youtrack.jetbrains.com/issue/RSRP-474628
The feature is sound and your setup is correct. Also the following works for me, i can compile and run the following in .Net Core 3
class Program
{
interface IDefaultInterfaceMethod
{
void DefaultMethod()
{
Console.WriteLine("I am a default method in the interface!");
}
}
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
Note though, i get your error in the IDE!! yet there was no error in the error window. However, it still compiles and runs so it is not C#8.. Seeing this is a sure-sign something else is the issue
In Short, this is likely a Resharper problem, when i suspended Resharper the false positive went away
Related
I have a MainForm class (as you'd expect, it is a form) that has a text box on it. I also have another class called 'Application_Server' That does a load of other stuff (not just form-background related, quite a lot of network based stuff etc.).
The Application_Server class runs in it's own thread, but needs to be able to update the controls on the form, for this question, we will stick with just the textbox.
The problem is that even though I am executing the command to set the text of the textBox control via 'Invoke' I am still getting the following exception during runtime:
Additional information: Cross-thread operation not valid: Control
'DebugTextBox' accessed from a thread other than the thread it was
created on.
What could be causing this? I am definitely invoking a delegate within MainForm.
Here are the relevant code segments (cut down for readability):
MainForm.h:
public ref class MainForm : public System::Windows::Forms::Form {
delegate void del_updateDebugText(String^ msg);
del_updateDebugText^ updateDebugText = gcnew del_updateDebugText(this, &MainForm::postDebugMessage);
private: void postDebugMessage(String^ message);
};
MainForm.cpp:
void EagleEye_Server::MainForm::postDebugMessage(String^ message)
{
Monitor::Enter(DebugTextBox);
if (this->DebugTextBox->InvokeRequired)
{
this->Invoke(updateDebugText, gcnew array<Object^> { message });
}
else
{
this->DebugTextBox->AppendText(message);
}
Monitor::Exit(DebugTextBox);
}
And finally, the code calling it:
void ServerAppManager::postDebugMessage(System::String^ message)
{
mainFormHandle->updateDebugText(message);
}
void ServerAppManager::applicationStep()
{
postDebugMessage("Starting\n");
// This is Run in seperate thread in MainForm.cpp
while (s_appState == ApplicationState::RUN)
{
postDebugMessage("Testing\n");
}
}
Thanks!
From background worker called bwSearch we do the call as following from the DoWork event handler:
private: System::Void bwSearch_DoWork(System::Object^ sender, System::ComponentModel::DoWorkEventArgs^ e) {
//... logic
UpdateTxtOutput("Some message");
//... more logic
}
I have a RitchTextBox called txtOutput, also the windows form control containing this code is called frmMain, the UpdateTxtOutput is defined in three parts as follows:
delegate void UpdateTxtOutputDelegate(String^ text);
void UpdateTxtOutput(String^ text)
{
UpdateTxtOutputDelegate^ action = gcnew UpdateTxtOutputDelegate(this, &frmMain::Worker);
this->BeginInvoke(action, text);
}
void Worker(String^ text)
{
txtOutput->AppendText("\t" + text + "\n");
}
I managed to get it working by simplifying the method within the 'MainForm' class to:
void EagleEye_Server::MainForm::postDebugMessage(String^ message)
{
Monitor::Enter(DebugTextBox);
DebugTextBox->AppendText(message);
Monitor::Exit(DebugTextBox);
}
And then moving the 'Invoke' call to the method calling the delegate, not pretty but it works for now. I think the issue may have been caused by the form getting stuck inside an Invoke loop. I say this as I noticed that the form would lock up and stop responding after it hit the recursive Invoke statement.
I have the following:-
[TestFixture]
class TaskServiceTest
{
public void Implements_ITaskService()
{
var service = CreateService();
Assert.That(service, Is.InstanceOf<ITaskService>());
}
private static ITaskService CreateService()
{
return null;
}
}
When I run that in Visual Studio / Resharper It is reported as 'Inconclusive'. The explanation of which in the NUnit Docs is
The Assert.Inconclusive method indicates that the test could not be completed with the data available. It should be used in situations where another run with different data might run to completion, with either a success or failure outcome.
I don't see that holding here, so can anyone explain what I am doing wrong?
Thanks
I just realised that it is because I missed the [Test] attribute off of the unit test.
[Test]
public void Implements_ITaskService()
{
var service = CreateService();
Assert.That(service, Is.InstanceOf<ITaskService>());
}
i started to work with .net remoting, read myself through tutorials and explanations, saw now at least three examples on the web and they looked all similar to my code. i can't find the reason for the error I get. (RemotingException was unhandled "Attempted to call a method declared on type 'System.IFormattable' on an object which exposes 'HES.MyProcess'.")
I tried to fix this for six hours now, unsuccessfully looking up the internet, reading through lots of pages...
Maybe you guys can help me out ?
MarshalByRefObject deriving class looks like:
public class MyProcess : MarshalByRefObject, IMyProcess
{
//public System.Diagnostics.Process process {get; set;}
public MyProcess()
{
// TODO: Complete member initialization
// this.process = Process.GetCurrentProcess();
}
public string GetProcessId()
{ Console.WriteLine("I'm on..");
return "test";
// return this.process.Id;
}
}
My interface loooks like this:
interface IMyProcess
{
string GetProcessId();
}
My server looks like this:
namespace HES
{
public class HES_Starter
{
public static void Main(string[] args)
{
// using TCP protocol
TcpChannel channel = new TcpChannel(_port);
//second value is for security settings
ChannelServices.RegisterChannel(channel, false);
Console.WriteLine("HES Server here... on PID: " + Process.GetCurrentProcess().Id);
//Type, objectUri to access the object remotely, mode
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(HES.MyProcess), "HESProcess",
WellKnownObjectMode.Singleton);
Console.ReadLine();
}
}
}
and finally my client like that:
namespace Service_Provider
{
public class Program
{
public static void Main(string[] args)
{
TcpChannel channel = new TcpChannel();
//second value is for security settings
ChannelServices.RegisterChannel(channel, false);
Console.WriteLine("HES Client here...");
IMyProcess remoteProcess = (IMyProcess)Activator.GetObject(
typeof(IMyProcess), "tcp://localhost:8050/HESProcess");
Console.WriteLine(remoteProcess);
Console.WriteLine(remoteProcess.GetProcessId());
Console.ReadLine();
}
}
}
does anybody have a clue what i'm doing wrong ?
I mean from the exception I can see that the client knows that the object is an remote object in the 'HES' namespace. And in debug I can see that the object
remoteProcess = {System.Runtime.Remoting.Proxies.__TransparentProxy}
is a proxy...
I don't know what i'm doing wrong here.
I'm trying to get VS2010 Ultimate with Code Contracts to generate Errors instead of Warnings.
I have this simple test program:
using System.Diagnostics.Contracts;
namespace MyError
{
public class Program
{
static void Main(string[] args)
{
Program prog = new Program();
prog.Log(null);
}
public void Log(string msg)
{
Contract.Requires(msg != null);
}
}
}
It correctly determines there is a violation of the contract:
C:\...\Program.cs(10,13): warning : CodeContracts: requires is false: msg != null
In my csproj file there is this property field for Debug:
TreatWarningsAsErrors>true
Is there something else I have to set in the project settings to turn these into errors?
It looks like at this point Microsoft has elected not to make this possible, but they are considering it for the future:
http://connect.microsoft.com/VisualStudio/feedback/details/646880/code-contracts-dont-listen-to-treat-warnings-as-errors-setting
The problem is that the code contracts use a rewriter. they show as warnings because they are only calculated after the build completes.
Well i don't really know how it works, but unless you built code contracts into the compiler i do not see how they could be anything but warnings / messages.
I developed a desktop application, it's almost done but still contains some bugs which I'm eliminating.
I use a general [try...catch] block wrapped around my application
[STAThread]
static void Main()
{
try
{
program = new Program();
// ...
}
catch (Exception x)
{
// ...
MessageBox.Show(
message,
Resources.MESSAGEBOX_ERROR_CRASH_Caption,
MessageBoxButtons.OK,
MessageBoxIcon.Error);
}
}
my Program class constructor being:
public Program()
{
// [...]
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
// [...]
frmLogon = new Logon();
Application.Run(frmLogon);
}
to ensure that any unhandled exception will bubble all the way up the stack and is at least responded to with some communicative message box.
It works fine when I run the application under Visual Studio (debug mode), but when I deployed it and installed on my PC, it doesn't - that's what I get when the bug (which I've already identified, by the way) causes it to read from a null array
Why? It baffles me really. Why was it "unhandled"? It was my understanding that try...catch should work regardless of whether it's release or debug mode, otherwise what would be the point.
This is kind of old, but if you still need a solution, you need to handle some events, enclosing the entire thing in a try catch won't work. Do something like this:
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
AppDomain.CurrentDomain.UnhandledException += ProcessAppException;
Application.ThreadException += ProcessThrException;
Application.Run(new MainForm());
}
private static void ProcessAppException(object sender, UnhandledExceptionEventArgs e)
{
XtraFunctions.LogException((Exception)e.ExceptionObject);
throw (Exception)e.ExceptionObject; //MessageBox in your case.
}
private static void ProcessThrException(object sender, ThreadExceptionEventArgs e)
{
XtraFunctions.LogException(e.Exception);
throw e.Exception; //MessageBox in your case.
}
When an exception isn't caught, it will go through one of those before displaying the exception dialog. So you have the option to override it and display a nice message of your choice.