The Uri constructor seems to be doing a lot of additional work when handling file: URIs, sometimes unfortunately to one's disadvantage. For example, file:///a%A4b is interpreted as file:///a%A4b/a%A4b via AbsoluteUri (and file://%2Fa%A4b/a%A4b in ToString() for some reason), and so is apparently every file URI that does not start with a drive letter and contains non-ASCII (even percent-encoded) characters.
Is it possible to disable this behaviour of file: URIs? It seems it has to be done globally, since I tried using different parameters in the constructor and it didn't work as well. I am fine with disabling any sort of special handling of file: URIs, since even (valid to my knowledge) URIs like file:a throw an exception due to that.
The issue seems to only crop up only in .NET Core up to 3.1. In .NET Framework or .NET 5, new Uri("file:///a%A4b") works as expected. Is there a way to get around this issue without upgrading or switching to .NET Framework?
This is a known issue in .NET Core prior to .NET 5. You will need to update to .NET 5.
Relevant links:
https://github.com/dotnet/runtime/issues/1031
https://github.com/dotnet/runtime/pull/36429
https://github.com/dotnet/docs/issues/19965
Is this rule applied to console applications? If yes, how can we log to the conosle then? Or why shouldn't you do it?
http://dist.sonarsource.com/plugins/csharp/rulesdoc/0.10.0-RC/S2228.html
You can disable this rule on Console Applications. Nevertheless, even for console applications, it can be a good idea to limit the number of Console.WriteLine() calls for instance to make it easier to later on change your application. For example, you don't want to see Console.* calls spread to the whole codebase, but see it perhaps contained in a single class. If that is the case, feel free to mark those issues as Won't Fix in SonarQube, to indicate that you have reviewed them and that they are expected and accepted.
you ca try to implement a sonar-project.properties file that would contain a sonar exclusions definition and you can exclude from Sonar scan the files containing console.log calls.
example:
sonar.exclusions=**/__tests__/**/*,**/*.js
The question is as simple as that: I need some way to identify composable part definitions before actually creating the parts.
In other words, I need to be able to send a string identifying the part to some remote site, which later would send the string back to me, and I should be able to pick that same part based on the string. I do not necessarily need a string (I can build my own map), but I need something that is unique and equality-comparable.
Some things I thought about and rejected:
I do realize that the "right" way for doing this is to decorate my parts with metadata, but I don't want to. First, using a meaningful string for identifier means risk of duplication, while using a random one (like GUID) means it would be ugly. Second, my plugins are numerous and I don't want to have to remember about decorating them all the time.
Another way that immediately jumps to mind is to use the part's type. However, MEF is generic enough to be above such formalities: a part is not necessarily a .NET class.
In trying to "fix" the previous point, I could use type of the actual object that is returned when I go and create the part, but then I would have to create all parts, which are numerous.
Metadata is really the only viable option, especially if you want the identifier to remain stable over time, e.g. in the face of application restarts or implementation class refactoring/renaming.
If you don't need stability between application restarts, you could either:
Use MEF 2's RegistrationBuilder to programmatically generate the necessary metadata values, e.g. based on an incrementing integer; or,
Create a custom [MetadataAttribute] that does roughly the same thing to generate an id value at runtime
If you need stability between restarts, but not between rebuilds, then using RegistrationBuilder to assign ids based on the type name is an option.
Of course, RegistrationBuilder is only available in the CodePlex preview builds of MEF 2 or the .NET 4.5 Developer Preview at this point.
TLDR; manually applying metadata attributes is your best bet. In debug mode you could write a post-initialisation routine in your app to ensure uniqueness/presence.
Anyone know where a computer keeps what parameters it can accept through this function? For example, I'd like to know what I can send to Winword.exe (Microsoft Word). Or is there an online list of what programs work here?
There's no standard means to query available command line parameters in executables. That's why you have to look online for published lists. For example Microsoft Word.
The Process.Start(..) overloaded methods pass various data into the process but cannot extract it because of the proprietary nature how a Process uses this info.
If you started the processes then Process.StartInfo may provide some useful information about how it was started (but does not reflect possibilities), and won't work as intended if you're just grabbing a process from memory that you didn't start.
Although it's customary for many Windows processes to allow /? to produce a list of parameters, and many systems use -help, /help or --help, etc, the output of even those may differ and be tough to consistently parse for discovery purposes.
Here is a list of accepted arguments for winword.exe Args list.
The command line arguments that an application accepts isn't stored anywhere on your hard drive, unless if there's specific documentation that came along with that product. That being said, google will be your best friend for this. Any app you think can be launched from the command line using different parameters, will have some info on the net.
you can either go to your application's help and find it there, or you can ask good old mr. Google to help you. if you are looking for Windows Word's args list, you can search for it on the support page of Microsoft. I believe there might be some changes from version to version.
Unix has a built-in documentation system for this: man pages. This is just one feature of Unix based OSs that shows how programmer-oriented it is (not a bad thing). Another would be the profileration of packaging and dependency systems.
Alas, no such standard exists for Windows.
I am making my switch from coding in C++ to C#. I need to replace my C++ error logging/reporting macro system with something similar in C#.
In my C++ source I can write
LOGERR("Some error");
or
LOGERR("Error with inputs %s and %d", stringvar, intvar);
The macro & supporting library code then passes the (possibly varargs) formatted message into a database along with the source file, source line, user name, and time. The same data is also stuffed into a data structure for later reporting to the user.
Does anybody have C# code snippets or pointers to examples that do this basic error reporting/logging?
Edit: At the time I asked this question I was really new to .NET and was unaware of System.Diagnostics.Trace. System.Diagnostics.Trace was what I needed at that time. Since then I have used log4net on projects where the logging requirements were larger and more complex. Just edit that 500 line XML configuration file and log4net will do everything you will ever need :)
Lots of log4net advocates here so I'm sure this will be ignored, but I'll add my own preference:
System.Diagnostics.Trace
This includes listeners that listen for your Trace() methods, and then write to a log file/output window/event log, ones in the framework that are included are DefaultTraceListener, TextWriterTraceListener and the EventLogTraceListener. It allows you to specify levels (Warning,Error,Info) and categories.
Trace class on MSDN
Writing to the Event Log in a Web Application
UdpTraceListener - write log4net compatible XML messages to a log viewer such as log2console
I would highly recommend looking at log4Net. This post covers the majority of what you need to get started.
Another good logging library is NLog, which can log to a lot of different places, such as files, databases, event logger etc.
I use The Object Guy's Logging Framework--as do most people who try it. This guy has some interesting comments about it.
Enterprise Library is a solid alternative to log4net and it offers a bunch of other capabilities as well (caching, exception handling, validation, etc...). I use it on just about every project I build.
Highly recommended.
Even though I personally hate it, log4net seems to be the de facto standard for C# logging. Sample usage:
log4net.ILog log = log4net.LogManager.GetLogger(typeof(Program));
log.Error(“Some error”);
log.ErrorFormat("Error with inputs {0} and {1}", stringvar, intvar);
As I said in another thread, we've been using The Object Guy's Logging Framework in multiple production apps for several years. It's super easy to use and extend.
Log4Net is a rather comprehensive logging framework that will allow you to log to different levels (Debug, Error, Fatal) and output these log statements to may different places (rolling file, web service, windows errors)
I am able to easily log anywhere by creating an instance of the logger
private static readonly ILog _log = LogManager.GetLogger(typeof([Class Name]));
and then logging the error.
_log.Error("Error messsage", ex);
Serilog is late to the party here, but brings some interesting options to the table. It looks much like classical text-based loggers to use:
Log.Information("Hello, {0}", username);
But, unlike earlier frameworks, it only renders the message and arguments into a string when writing text, e.g. to a file or the console.
The idea is that if you're using a 'NoSQL'-style data store for logs, you can record events like:
{
Timestamp: "2014-02-....",
Message: "Hello, nblumhardt",
Properties:
{
"0": "nblumhardt"
}
}
The .NET format string syntax is extended so you can write the above example as:
Log.Information("Hello, {Name}", username);
In this case the property will be called Name (rather than 0), making querying and correlation easier.
There are already a few good options for storage. MongoDB and Azure Table Storage seem to be quite popular for DIY. I originally built Serilog (though it is a community project) and I'm now working on a product called Seq, which provides storage and querying of these kinds of structured log events.
You can use built in .NET logging. Look into TraceSource and TraceListeners, they can be configured in the .config file.
Ditto for log4net. I'm adding my two bits because for actual use, it makes sense to look at some open source implementations to see real world code samples with some handy additions. For log4net, I'd suggest off the top of my head looking at subtext. Particularly take a look at the application start and assemblyinfo bits.
Further to the couple of comments realting to the use of the System.Diagnostics methods for logging, I would also like to point out that the DebugView tool is very neat for checking debug output when needed - unless you require it, there is no need for the apps to produce a log file, you just launch DebugView as and when needed.
The built in tracing in System.Diagnostics is fine in the .NET Framework and I use it on many applications. However, one of the primary reasons I still use log4net is that the built in .NET Framework tracing lacks many of the useful full featured appenders that log4net already supplies built in.
For instance there really isn't a good rolling file trace listener defined in the .NET Framework other than the one in a VB.NET dll which really is not all that full featured.
Depending on your development environment I would recommend using log4net unless 3rd party tools are not available, then I'd say use the System.Diagnostics tracing classes. If you really need a better appender/tracelistener you can always implement it yourself.
For instance many of our customers require that we do not use open source libraries when installed on their corporate machines, so in that case the .NET Framework tracing classes are a perfect fit.
Additionally - http://www.postsharp.org/ is an AOP library I'm looking into that may also assist in logging as demonstrated here on code project:http://www.codeproject.com/KB/dotnet/log4postsharp-intro.aspx.
ExceptionLess is one of the easiest nuget package available to use for logging. Its an open source project. It automatically takes care of unhandled exception, and options for manually logs are available. You can log to online or self host on local server.
Log4Net, as others have said, is fairly common and similar to Log4j which will help you if you ever do any Java.
You also have the option of using the Logging Application Block http://www.codeproject.com/KB/architecture/GetStartedLoggingBlock.aspx