I'm working on a SignalR app. The app automatically serializes message to JSON. However I have noticed that enums not markes as [Serializable] cause the messages to fail to be send.
For the enums that I created it's a simple fix. Just add the attribute.
But how do I fix the enums that are .Net framework enums? On my model that I'm passing I have a copy of the FileSystemWatcher's WatcherChangeTypes enum. Since I can't mark the enum as [Serializable] the service call fails.
I thought of two possible fixes:
1) Create my own enum and copy the .Net values to mine
2) Use an int value and cast/uncast the enum value as needed.
Anyone have any insight on this? I'd really prefer to just be able to use the .Net enums.
You can't, not in practice.
The reason you can't do it with images is because most email applications don't load images so that the email can't be tracked: too many spammers / phishers were using it to identify "live" email addresses and target them specifically.
Unfortunately, that means that "legitimate" uses of such tracking can't do it either. The only reliable way to track emails now is to include a link that the user needs to respond to.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
If you use ReSharper, there is an option to switch to explicit Type declaration from 'var via either a left-margin click on an icon, or by keyboard alt-enter.
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
ReSharper is the demon responsible for most of this var nonsense!
// Can you guess what VS plug-in I use?var customers = ctx.Customers.Where(c => c.HasOrders);
var customer = customers.FirstOrDefault();
if (customer != null)
var orderCount = customer.Orders.Count;
varvalue = customer.Orders.Sum(o => o.Total);
var postage = ctx.Postage.Where(p => P.Country == customer.Country);
var valuePlusPostage = value += postage;
var tax = financeHelper.TaxRate;
But if you don't like the option that changes a fully-specified type to 'var', why are you using it? I'm assuming here that Resharper doesn't do that by itself, or if it does that it is a 'feature' that can be turned off.
(No, I am not using Resharper myself, never have)
(Yes, I do prefer 'var': it saves keystrokes; intellisense provides me with the name of type if I need it)
I don't use resharper myself but most of my colleagues do. In its default configuration it flags a warning on any use of explicit types, suggesting you use var instead. Yes it can be turned off, but no-one does. And yes it can also be ignored, but people would rather just use var to get rid of the wiggly line (see previous comment).
not how it affects reviewers. But fair enough I guess.
Who does your code reviews if it's not developers?
If you know what GetDescendant() does, then you'll know the return type (assuming here).
And what happens when you're reviewing a piece of code that calls a method that was written 5 years ago that you have never had cause to look into? You're introducing blockers for reviewers just because you can't be bothered to type the full type.
What is more important, the method and what it does, or the specific technical return type?
If you don't know the return type, how can you tell if the person whose code you're reviewing is using the type properly or that it will even compile? You have to give people the context to help them.
var is a Microsoft mechanism that allows VB last-resorters to be okay with using as more appropriate strongly-typed language rather than comply with the actual paradigm of being a real programmer.
In essence, it is the "safe space" of programming constructs and as such, is used only by flaming lib-tards that think all code should be equal in the eyes of the compiler.
THAT is what's wrong with var.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 - You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 - When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013