We updated Nancy from v1.2.0 to 1.3.0 via NuGet. According to the changelog there appear to be no breaking changes relevant to our application. However we are now getting the runtime error
Method not found: 'Nancy.ErrorPipeline
Nancy.ErrorPipeline.op_Addition(Nancy.ErrorPipeline,
System.Func`3)'.
in
base.ApplicationStartup(container, pipelines);
in our CustomBootstrapper. We are using Nancy.Bootstrappers.Autofac and have a custom IStatusCodeHandler.
I have cleaned out the packages folder, as well as bin/obj folders, and verified that there is only one version of Nancy after package restore.
How can I resolve or troubleshoot this?
(Caveat: I've never used Nancy. This is just a matter of looking at the history in Github.)
It looks like the + operator signature you're using changed from this in 1.2.0:
public static ErrorPipeline operator +
(ErrorPipeline pipeline, Func<NancyContext, Exception, Response> func)
to this in 1.3.0:
public static ErrorPipeline operator +
(ErrorPipeline pipeline, Func<NancyContext, Exception, dynamic> func)
That's not a backwardly-compatible change, at the very least at the binary level. As far as the CLR is concerned, that signature will be
public static ErrorPipeline operator +
(ErrorPipeline pipeline, Func<NancyContext, Exception, object> func)
... so any binary with a reference to the earlier signature won't find what it's looking for.
Do any of your dependencies also depend on Nancy, possibly at v1.2.0? Basically, you need to find out which piece of code is expecting the old signature, so you can rebuild that code against 1.3.0.
Related
When I throw an exception in my ASP.NET Core 3.1 code, fxcop warns me when it sees a string literal as an argument to a new Exception(). For example:
throw new InvalidOperationException("Ouch");
gives me CA1303: Do not pass literals as localized parameters
As a general rule, I don't display exception messages to end users, so I have no desire to localize them. Is there a way to configure CA1303 so that it ignores constructor arguments on anything that derives from System.Exception?
EDIT:
After a bit more searching, I've found this conversation about exactly this problem:
https://github.com/dotnet/roslyn-analyzers/issues/2933
If you are using .editor config, you could do this: dotnet_code_quality.CA1303.use_naming_heuristic = true
Or completely disable CA1303.
Version 3.3.0 of Microsoft.CodeAnalysis.FxCopAnalyzers finally fixed the ability to suppress the warning when calling specific types.
In order to suppress CA1303 when constructing an Exception or when calling an ILogger function, I added a .editorconfig file to the root directory of my solution (all of the projects are subdirectories of this directory) and added these lines to it:
[*.cs]
dotnet_code_quality.CA1303.excluded_type_names_with_derived_types = Exception|LoggerExtensions|ILogger
This tells CA1303 to ignore calls into Exception, LoggerExtensions, and ILogger (and any type that derives from these types).
For reference, see this issue and the reply beneath it:
https://github.com/dotnet/roslyn-analyzers/issues/2933#issuecomment-627256340
I have a PoC to use some existing Java-codebase in some UWP-app using the most current Visual Studio Community 19 version 16.3.2 and the latest released IKVM 8.1.7195.0. The app builds and runs fine in Debug-mode, but fails to build already in Release-mode with the following error:
MCG0004:InternalAssert Assert Failed: ICE: trying to add a local var
with the same name, but different types. during
[_RegisterClipboardFormat] Ams.Oms.Poc
RegisterClipboardFormat is part of IKVM:
#DllImportAttribute.Annotation(value = "user32.dll", EntryPoint = "RegisterClipboardFormat")
private native static int _RegisterClipboardFormat(String format);
#cli.System.Security.SecuritySafeCriticalAttribute.Annotation
private static int RegisterClipboardFormat(String format)
{
return _RegisterClipboardFormat(format);
}
https://github.com/ikvm-revived/ikvm/blob/master/openjdk/sun/awt/IkvmDataTransferer.java#L95
What I'm wondering is which local variable the error message is referring to? Might be something added implicitly or might have to do with String in Java vs. string in C#? OTOH that file is clearly named .java.
Didn't find much about the error message in general, only the following two links seems to be more interesting:
Variables having same name but different type
Why doesn't C# allow me to use the same variable name in different scopes?
So I'm currently even unsure where the message comes from, Visual Studio/C# directly or IKVM during running code during building Release-mode. I strongly suspect the error is coming from Visual Studio/C#, though.
Searching for the function itself doesn't reveal much of help as well:
Sorry, AWT is not a supported part of IKVM.
https://sourceforge.net/p/ikvm/bugs/225/
Others seemed to have the same problem, because CN1 simply disabled that code entirely in their fork of IKVM:
//#DllImportAttribute.Annotation(value = "user32.dll", EntryPoint = "RegisterClipboardFormat")
//private native static int _RegisterClipboardFormat(String format);
#cli.System.Security.SecuritySafeCriticalAttribute.Annotation
private static int RegisterClipboardFormat(String format)
{
throw new Error("Not implemented");
//return _RegisterClipboardFormat(format);
}
https://github.com/ams-ts-ikvm/cn1-ikvm-uwp/blob/master/openjdk/sun/awt/IkvmDataTransferer.java#L95
Any ideas? Thanks!
There seems to be a workaround by not changing any code at all: The settings of the Release-build contain a checkbox if to use the .NET native toolbox for the build, which is enabled by default. By disabling that the build succeeds without any code change and is as fast as the Debug-build again. Before changing that, the Release-build took a lot longer as well.
Don't know what that means regarding actually calling native code, if that fails or not, because my app doesn't use those. I guess it would fail, depending on if it works in Debug or not. Additionally, I'm not sure if the Windows store accepts such a modified Release-build, but as UWP-apps aren't forced to use native code at all, I guess there's a good chance things are going to work.
I am using ILMerge and Quartz.NET in a C# .NET 4.0 Windows Service application. The app runs fine without using ILMerge, but now that we're nearing shipping release, I wanted to combine all DLLs into a single executable.
Problem is, that ILMerge seems to work fine, but when I run the combined executable, it throws this exception:
Unhandled Exception: Quartz.SchedulerException: ThreadPool type 'Quartz.Simpl.SimpleThreadPool' could not be instantiated. ---> System.InvalidCastException: Unable to cast object of type 'Quartz.Simpl.SimpleThreadPool' to type 'Quartz.Spi.IThreadPool'.
at Quartz.Util.ObjectUtils.InstantiateType[T](Type type) in :line 0
at Quartz.Impl.StdSchedulerFactory.Instantiate() in :line 0
--- End of inner exception stack trace ---
at Quartz.Impl.StdSchedulerFactory.Instantiate() in :line 0
at Quartz.Impl.StdSchedulerFactory.GetScheduler() in :line 0
Does anyone have any idea why this is? I have been wasting over 4 hours already and I can't figure it out. If I don't combine with ILMerge, then everything runs fine (with the Quartz.dll and Common.Logging.dll in the same directory).
I'm sure someone must have tried packaging Quartz.net up like this before, any ideas?
Disclaimer: I don't know Quartz.NET at all, although I spent some time struggling with ILMerge. When I finally understood its limitations... I stopped using it.
ILMerge'd application tends to have problems with everything which contains the word "reflection".
I can guess (I've never used Quartz.NET) that some classes are resolved using reflection and driven by configuration files.
Class is not only identified by its name (with namespace) but also by assembly it is coming from (unfortunatelly it doesn't get displayed in exception message).
So, let's assume you had (before ILMerging) two assemblies A (for you Application) and Q (for Quartz.NET).
Assembly 'A' was referencing assembly 'Q' and was using a class 'Q:QClass' which was implementing 'Q:QIntf'.
After merging, those classes became 'A:QClass' and 'A:QIntf' (they were moved from assembly Q to A) and all the references in code has been replaced to use those (completely) new classes/interfaces, so "A:QClass" is implementing "A:QIntf" now.
But, it did not change any config files/embedded strings which may still reference "Q:QClass".
So when application is reading those not-updated config files it still loads "Q:QClass" (why it CAN find it is a different question, maybe you left assembly 'Q' in current folder or maybe it is in GAC - see 1).
Anyway, "Q:QClass" DOES NOT implement "A:QIntf", it still implements "Q:QIntf" even if they are binary identical - so you can't cast 'Q:QClass' to 'A:QIntf'.
The not-ideal-but-working solution is to "embed" assemblies instead of "merging" them. I wrote a open-source tool which does it (embedding instead of merging) but it is not related to this question. So if you decide to embed just ask me.
You can test it by removing (hiding, whatever works for you) every single instance of Q.dll on your PC. If I'm right, the exception should say now 'FileNotFound'.
You could try creating your own ISchedulerFactory and avoid using reflection to load all of your types.
The StdSchedulerFactory uses this code to creat a threadpool. It's where your error is happening and would be the place to start looking at making changes:
Type tpType = loadHelper.LoadType(cfg.GetStringProperty(PropertyThreadPoolType)) ?? typeof(SimpleThreadPool);
try
{
tp = ObjectUtils.InstantiateType<IThreadPool>(tpType);
}
catch (Exception e)
{
initException = new SchedulerException("ThreadPool type '{0}' could not be instantiated.".FormatInvariant(tpType), e);
throw initException;
}
The ObjectUtils.InstantiateType method that is called is this one, and the last line is the one throwing your exception:
public static T InstantiateType<T>(Type type)
{
if (type == null)
{
throw new ArgumentNullException("type", "Cannot instantiate null");
}
ConstructorInfo ci = type.GetConstructor(Type.EmptyTypes);
if (ci == null)
{
throw new ArgumentException("Cannot instantiate type which has no empty constructor", type.Name);
}
return (T) ci.Invoke(new object[0]);
}
Right after this section in the factory, datasources are loaded using the same pattern and then the jobs themselves are also loaded dynamically which means you'd also have to write your own JobFactory. Since Quartz.Net loads a bunch of bits and pieces dynamically at runtime going down this road means you might end up rewriting a fair amount of things.
I'm currently using CloudConfigurationManager.GetSetting("setting") to get settings for my application, but it's writing logs of everything it's checking to the console (in both Debug and Release):
Getting "setting" from ServiceRuntime: FAIL.
Getting "setting" from ConfigurationManager: PASS (Data Source=...
Getting "setting" from ServiceRuntime: FAIL.
Getting "setting" from ConfigurationManager: PASS (Data Source=...
Is there any way to prevent it from doing this, or an alternative version that's less verbose?
Mostly I just like my unit test output to be nice and clean, but I'm also a little concerned that it's printing out things like connection strings (and hence passwords) in plain text on the production server.
CloudConfigurationManager.GetSetting now has a method overload with a parameter called outputResultsToTrace.
If you pass false to this method, then it'll disable the Trace.WriteLine used elsewhere to "spam" the Trace log.
So
var mySetting = CloudConfigurationManager.GetSetting("MySetting");
becomes
var mySetting = CloudConfigurationManager.GetSetting("MySetting", false);
I found this by looking directly at the source code on GitHub: https://github.com/Azure/azure-sdk-for-net/blob/52fc67253a176bea01c37c164f71c7eba8eaedba/src/Common/Configuration/CloudConfigurationManager.cs#L35
It's probably worth mentioning that this overload is not documented: https://msdn.microsoft.com/en-us/library/azure/mt634648.aspx
So I'm not sure if it's an official and supported part of the API, or if it's something that might change or go away in the future.
This change was made at the end of 2015: https://github.com/Azure/azure-sdk-for-net/commit/e14398136d7d3b6d5e4675f1e8ccbdd37a8c6b01
Not really. If you look at the code of the underlying GetValue method you'll see this:
private static string GetValue(string providerName, string settingName, Func<string, string> getValue)
{
string str1 = getValue(settingName);
string str2;
if (str1 != null)
str2 = string.Format((IFormatProvider) CultureInfo.InvariantCulture, "PASS ({0})", new object[1]
{
(object) str1
});
else
str2 = "FAIL";
Trace.WriteLine(string.Format((IFormatProvider) CultureInfo.InvariantCulture, "Getting \"{0}\" from {1}: {2}.", (object) settingName, (object) providerName, (object) str2));
return str1;
}
The Trace.WriteLine is always called without taking into account Debug or Release. Now you can simply remove the Default listener which should suppress all messages:
<system.diagnostics>
<trace>
<listeners>
<remove name="Default" />
</listeners>
</trace>
</system.diagnostics>
Now if you look at the CloudConfigurationManager it doesn't do that much. If this is a problem for you you can cook up something yourself, starting with this:
if (RoleEnvironment.IsAvailable)
return RoleEnvironment.GetConfigurationSettingValue(setting);
else
return ConfigurationManager.AppSettings[setting];
Note: The CloudConfigurationManager does a lot more than this, like loading the assembly without assembly reference.
Alternative option, if you're calling CloudConfigurationManager.GetSetting() in one part (ie, a wrapper/helper class):
var oldListeners = Trace.Listeners.Cast<TraceListener>().ToArray();
Trace.Listeners.Clear();
var stringValue = CloudConfigurationManager.GetSetting(key);
Trace.Listeners.AddRange(oldListeners);
First, we remove all listeners on Trace. Then we grab the setting, and re-add the listeners. Of course, this potentially could cause problems with threaded applications
I just installed the nuget package Microsoft.WindowsAzure.ConfigurationManager version 3.1.0, and I can confirm that the issue has been fixed in this version. Taking a look at the github issue referenced in the question's comments, we can see, in the changelog, the fetched value is no longer written to the trace output. In particular, the trace message has been changed from:
message = string.Format(CultureInfo.InvariantCulture, "PASS ({0})", value);
to:
message = "PASS";
This still makes the configuration manager quite verbose though.
We just ran into this ourselves...so very frustrating.
We can't remove the default listener because we are logging our own stuff on it.
There is an easy workaround though. Just use the good old fashioned ConfigurationManager.AppSettings["Microsoft.ServiceBus.ConnectionString"] and you will get the info you need without the annoying logging.
Hope that helps,
David
I had quite similar problems. I updated from Azure SDK 2.0 to 2.2 - during this process I used the NuGet Manager to update the Microsoft.WindowsAzure.Storage to the latest. The PackageManager automatically took Microsoft.WindowsAzure.Configuration to 1.8.0.0. I was not able to get this running (it was for .Net 2.0!?). After I manually set all References to
Microsoft.WindowsAzure.Storage 2.1.0.0
Microsoft.WindowsAzure.Configuration 2.0.0.0
everything worked.
I think this is because of the way CloudConfigurationManager.GetSetting loads the assembly and calls the funktions (via reflection).
Fixed in version 3.0.0. Please update Microsoft Azure Configuration Manager nuget package.
There are two separate issues here:
Setting values are logged in plain text (a security concern)
Messages are logged every time a setting is retrieved (a verbosity concern)
As others have noted, #1 has been fixed in a more recent version of the plugin.
Based on my experience (and some of the other responses here), #2 is still a huge annoyance.
Looking at WADLogsTable in Visual Studio's Queue Editor, note that the message level is 5 (i.e. verbose, according to this list of ETW levels).
Going off of the diagnostic config file schema, my approach to solving issue #2 was to limit the minimum severity level (e.g. warning, informational, verbose) of generic tracing to "information" (or more severe) and just ensure my own logging did not use the "verbose" level.
Here is the change I made in diagnostics.wadcfgx:
Original:
<Logs scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Verbose" />
Fixed:
<Logs scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Information" />
I was under the impression Mono's compiler was usable in Microsoft.NET
edit: updated blog posting here that I originally missed that explains some of it (is consistent with Justin's answers)
I created a simple class to try to use it
[TestFixture]
class Class1
{
[Test]
public void EXPR()
{
Evaluator.Run("using System;");
int sum = (int)Evaluator.Evaluate("1+2");
}
}
And a project in Visual Studio 2010 that references C:\Program Files (x86)\Mono-2.10.1\lib\mono\4.0\Mono.CSharp.dll.
However when I try to run this task I get the following exception, thrown at the Evaluator.Run call:
System.TypeInitializationException was unhandled by user code
Message=The type initializer for 'Mono.CSharp.Evaluator' threw an exception.
Source=Mono.CSharp
TypeName=Mono.CSharp.Evaluator
StackTrace:
at Mono.CSharp.Evaluator.Run(String statement)
at Experiments.Class1.EXPR() in W:\Experiments\Class1.cs:line 16
InnerException: System.TypeLoadException
Message=Method 'Mono.CSharp.Location.ToString()' is security transparent, but is a member of a security critical type.
Source=Mono.CSharp
TypeName=Mono.CSharp.Location.ToString()
StackTrace:
at Mono.CSharp.Evaluator..cctor()
InnerException:
A google confirms one other person asking this question but no answer. I tried to start reading the microsoft article on security transparent code but got confused quite quickly. Would someone be able to suggest a quick workaround to allow me to use this? And possibly summarise the security implications, if any, to me (in the context of my situation - in the future I hope to package it with a thick client application, to be used both internally and by end-users)
It has worked under .NET since April of last year.
Small point but I notice you are missing a semi-colon in your expression for sum.
int sum = (int)Evaluator.Evaluate("1+2;");
I only have Mono 2.11 (from git) at the moment and they have changed to using a multi-instance version of the compiler instead of the static version. So, my code looks a little different:
using System;
using Mono.CSharp;
namespace REPLtest
{
class MainClass
{
public static void Main (string[] args)
{
var r = new Report (new ConsoleReportPrinter ());
var cmd = new CommandLineParser (r);
var settings = cmd.ParseArguments (args);
if (settings == null || r.Errors > 0)
Environment.Exit (1);
var evaluator = new Evaluator (settings, r);
evaluator.Run("using System;");
int sum = (int) evaluator.Evaluate("1+2;");
Console.WriteLine ("The sum of 1 + 2 is {0}", sum);
}
}
}
EDIT: I guess I should confirm that I did in fact successfully execute this on .NET 4 (using Visual C# Express 2010 on Windows XP)
EDIT AGAIN: If you have Visual Studio, you can download the latest version of Mono.CSharp and compile it yourself. There is a .sln (solution file) included with the source so you can build it on Windows without Mono. The resulting assembly would run the code above. Miguel has a post explaining the new Mono.CSharp here.
FINAL EDIT: I uploaded the compiled Mono.CSharp.dll assembly that I actually used here. Include it as a reference to compile the code above.
It looks like this is a bug in Mono.
.NET 4 abandoned Code Access Security but kept the concept of Security Transparent Code. In a nutshell, low-level code that does stuff, like call unmanaged code, must be "security critical". Application level code is marked "transparent". "Transparent" code cannot call into "security critical" code.
It sounds like Mono.CSharp.Location.ToString() needs to be marked with the [SecuritySafeCritical] attribute if you want the Mono 2.10 code to work with .NET 4. Maybe even better would be marking all of Mono.CSharp as SecuritySafeCritical.
http://msdn.microsoft.com/en-us/library/system.security.securitycriticalattribute.aspx
PS. Sorry to have multiple answers for one question. After I realized that 2.11 would work, I became more curious about what the error with 2.10 meant. I cannot really combine this answer with the others.
I decided I should have kept the code more like the question but I did not want to overwrite my previous answer:
The code below works with version 2.11 of Mono.CSharp (available here including a solution file for building with Visual Studio/.NET). It was tested with .NET 4 on Windows XP. I do not have access to Mono 2.10 at the moment.
[TestFixture]
class Class1
{
private Evaluator evaluator;
public Class1()
{
var report = new Report(new ConsoleReportPrinter());
evaluator = new Evaluator(new CompilerSettings(), report);
}
[Test]
public void EXPR()
{
evaluator.Run("using System;");
int sum = (int)evaluator.Evaluate("1+2;");
}
}
EDIT: I uploaded the Mono.CSharp.dll assembly that I actually used here. Include it as a reference to compile the code above.