We recently hit a bug in our code that was caused by a subtle difference in how DevForce behaves under Silverlight compared to non-Silverlight environments. We found out the hard way that when DevForce raises an 'all properties have changed' event in Silverlight, it does so by using string.Empty in the PropertyChanged event. However, in non-Silverlight null is used instead. This wasn’t that hard of a fix on our end – we likely should have been watching out for either null or string.Empty all along. But it got us worried if there are other subtle differences like this that we should be looking out for.
Are there any other known differences between Silverlight and non-Silverlight like this? Obviously there are some differences such as Silverlight not allowing synchronous queries...but that is well documented. I'm looking for small things like this which might break code that previously worked fine in Silverlight.
Sorry you ran into the PropertyChanged issue. That divergence actually came about due to an old bug in the SL DataForm, but it's never been re-addressed in DevForce because MS documentation does say that both null and the empty string do the same thing. FWIW, DF uses the empty string here in all non-full .NET environments.
We don't have any documentation on these subtle differences. In general, most environment differences result in a different surface area, usually with a reduced API. So as you noted the synchronous methods are only found in the .NET assemblies, while you'll find XAP-related APIs in the SL assemblies. Other "missing" or changed features would be things like file I/O and .config file handling.
In general DF tries to rationalize the APIs and behaviors across environments, although there can be subtle differences or performance impacts in the underlying implementations. For example, WCF, composition (MEF), serialization and reflection are a few areas which we've found don't always work quite the same across environments, although we've tried to mitigate these within DevForce so apps don't see the issues. DF also has shim/dummy implementations for some attributes (mostly for ODATA and data annotations) in non-.NET environments, which could cause issues if you're expecting the real types.
I've scanned for a few differences which might not be obvious: 1) a parameterless constructor is required when cloning in non-.NET, 2) compile-time validation of the use of the ProvideEntityAspect and ProvideComplexAspect attributes is done only in .NET, 3) attempts to do encryption/decryption with the FIPS parameter set will throw a NotSupportedException in non-.NET.
There are differences in design-time support too. In SL weird security and serialization exceptions will be thrown by VS when using the ECS or using design-time data based on a code first model.
I should also note that if you're doing .NET unit testing of your SL code you cannot assume the code will also work in SL. You really need to test in SL too to avoid surprises.
If you have questions about any specific areas of DevForce or run into any unexpected environment differences let us know.
Related
I am new to C#, programming for less than a year. Until now I have been using the Micrsoft SQLHelper class. (copy of text header below) I recently came across Dapper.
Question is, should I switch to using Dapper ?
Although the SQLHelper class has worked with no issues, I don't know how old it is and I don't have enough experience to determine whether I should switch to using Dapper for xyz reasons. Is Dapper the preferred long term solution?
Thanks
// Microsoft Data Access Application Block for .NET // SQLHelper.cs //
// This file contains the implementations of the SqlHelper and
SqlHelperParameterCache // classes.
Is EntLib doing what you need and not inconveniencing you? Then: perhaps stay with it. Dapper would probably be more convenient in a lot of ways, and EntLib is arguably taking a complex API (ADO.NET) and making it more complex (as opposed to Dapper which aims to make things simpler for the caller), but: if the code works... shrug.
If you were starting from scratch, I'd 100% say "don't go near EntLib with a barge pole, Dapper is fine" (disclosure: I'm a little biased), but: if your code is working today, probably best not to touch it unless you have time to fix any problems you get while moving cogs.
Can anybody shed any light on how I can use the precompiled protobuf-net serializer assembly with WCF and a client (not to serialize/deserialize in code) to speed up first use of a DTO type?
I have managed to gain a lot of petrformance improvement in my large WCF/WPF application by using protobuf-net vs. datacontractserializer. However, even though I can precompile a serialization assembly from my DTO's, I cannot make WCF or it's WPF Client use it. The web service process always takes a long time for any first call from that process involving a new DTO, presumably to generate a serialization assembly on the fly.
How can I instruct the WCF server and/or the WPF client to use my generated assembly?
On a related issue, I have properties of type SolidColorBrush in some DTO's and this makes the precompiler fall over with "No serializer defined for type: System.Windows.Media.SolidColorBrush".
I have some code to add this support to the protobuf-net model, but I cannot understand how to apply it (to the precompiler or my code), when the rest of the DTO's are decorated with attibutes e.g. ProtoContractAttribute.
Any help much appreciated
At the moment, the only way to make WCF use a precompiled model would be configure WCF manually through code, in particular adding a ProtoOperationBehavior manually, and specifying the model:
var behavior = new ProtoOperationBehavior();
behavior.Model = new MyPrecompiledSerializer();
I confess I don't have a full end-to-end WCF example of doing that. I suspect it may be easier for me, in a new release, to tweak ProtoBehaviorExtension and/or ProtoBehaviorAttribute to allow you to specify the custom serializer-type via configuration - but that code does not exist today.
In the interim, if the issue is a slight delay on the first operation, then you can also add a few of the types you need exlicitly toe the default model, and compile it:
RuntimeTypeModel.Default.Add(typeof(Foo), true);
RuntimeTypeModel.Default.Add(typeof(Bar), true);
RuntimeTypeModel.Default.CompileInPlace();
that said: the compilation isn't horrendously slow - I'd be a little surprised if it is causing noticeable delay, unless your model is really complex (hundreds of types). Is it possible the delay is just WCF, network, TCP, etc overheads?
Regarding SolidBrush, and by implication: Color - it is possible to configure them at runtime:
RuntimeTypeModel.Default.Add(typeof(System.Windows.Media.Color), false)
.Add("R", "G", "B", "A");
RuntimeTypeModel.Default.Add(typeof(System.Windows.Media.SolidColorBrush), false)
.Add("Color");
However, I have not yet added a mechanism to do this when using "precompile" - it is much trickier at the technical level: I can't just use an executable method on (say) an attribute, because the assembly being inspected by "precompile" could be for any CLI (Silverlight, WinRT, .NET 1.1, CF, etc) - and as such, it is loaded by very different mechanisms.
My preferred approach would be: don't expose it as System.Windows.Media.Color - write your own DTO class that represents the data (rather than the final implementation), and map between them. Alternatively, it is also possible to write your own utility console exe that acts like "precompile", by configuring the model then calling RuntimeTypeModel.Default.Compile(string,string) or RuntimeTypeModel.Default.Compile(CompilerOptions).
Good day!
I want to distribute the c# application and want protect it.
I need:
obfuscation - protection of the source code + text resource files.
error reporting - a report on Unhandled Error.
clear view obfuscated stack trace
ensure there are no changes to source code.
What problems can get out due to the obfuscation (eg serialization / deserialization / reflection / globalization)? Appreciate the complexity of solutions this problems?
What methods / tools / approaches you recommend?
Thanks for help!
Disclaimer: I work for Red Gate.
SmartAssembly does what you're after. For your points in turn:
1) It does control flow obfuscation, method / field renaming, compression / encryption of resources and embedded strings, and separation of methods from their containing classes.
2) Automated error reporting automatically detects and reports unhandled execptions (it also grabs and sends the stack trace, values of all local variables, and some general system info).
3) The obfuscated stack trace gets decoded again on your machine so you can see it in clear view.
4) Not 100% that I know what you mean by this, but tamper protection prevents the app from running at all if any modifications are made to it. If you mean you don't want to make changes to your own source code, it is run as a post-build process so doesn't need any changes to be made to the source.
Re problems you might get with obfuscation, by far the most common are because of reflection (as a result WPF often causes problems), and data binding causes lots of issues too. Most obfuscators should let you exclude individual types and methods which have problems with reflection, though obviously that leaves those types and methods unprotected.
There are other obfuscators too - I know a couple of people who use one from PreEmptive called dotfuscator.
Crypto Obfuscator supports all the features you are looking for including obfuscation, code-protection as well as Exception Reporting (with automatic de-obfuscation as well as full values of all method parameters and local variables).
Another unique feature of Crypto Obfuscator is the Warnings tab shown after obfuscation. This lists all lines of code in your assemblies which can potentially cause the obfuscated assembly to fail. SO you don't have to shoot in the dark trying to figure out why obfuscated assemblies are not working.
DISCLAIMER: I work for LogicNP Software, the developer of Crypto Obfuscator.
Normally, I put what I consider the constitutional root resources, such as brand colours/brushes, fonts and sizes down in the 'distrib' assembly.
The Distrib assembly|ies are designed to go out to 3rd party dev shops, so they have access our contracts, interfaces, and branding styles.
More complex resources are then built up and declared 'nearer' where they're used.
I've come along to an application that has grown organically, err, haphazardly. What's odd is that the modules use resources from the main app executable project, even though the modules don't reference the app.
I assume that because they're 'importing' all the resources into App.xaml, they're available to the psuedo-runtime designer context.
My question is
If this is how MS designed it to work, have I been doing it wrong all along by managing resources like I do a type system?
Thanks
Luke
** UPDATE **
So, it was pointed out to me that well organised resources are not the way to go in WPF due to a severe performance problem (much as I had found in a big SL4 app I worked on, but assumed it was an SL thing).
Assuming that managing resources in this highly organised way can still be done with a trick or two, and that modular systems often need to merge dictionaries, I began to look into using Christian Moser's SharedResourceDictionary solution, but I get a problem at design time only:
System.IO.Packaging.PackUriHelper
The URI prefix is not recognized.
at System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase)
at System.Net.WebRequest.Create(Uri requestUri)
at MS.Internal.WpfWebRequestHelper.CreateRequest(Uri uri)
at System.Windows.ResourceDictionary.set_Source(Uri value)
at CompanyName.Presentation.SharedResourceDictionary.set_Source(Uri value)
It looks like it doesn't understand the pack Uris, which is odd since the SharedResourceDictionary just calls down to the original MS implementation in ResourceDictionary, and registering the pack URI scheme statically doesn't help either!! Grrr.
So I need to crack on and the second option is to smash everything into App.xaml and avoid merged dictionaries.
This means fewer controls/views, and setting up a design-time dictionary in my distributable library which I guess does the job of the app.xaml which they won't have access to.
I think that makes sense.
Interesting? Tell Microsoft
It may be for Silverlight, but I'm hoping the WPF folks might be listening, or at least it might fix one platform -- I've added an 'idea' to the UserVoice site that you can vote up.
http://dotnet.uservoice.com/forums/4325-silverlight-feature-suggestions/suggestions/2307678-fix-the-mergeddictionary-perf-problem
Yes, the App.xaml thing seems to be kind of how it's 'supposed' to work, although obviously other ways are possible as you've found. The performance problem is irritating though, and the App.xaml way is also irritating because they don't resolve at design time (at least, they don't for us, if they do for you I want to know why).
However, putting them in App.xaml is the only technique I've found anything approaching an 'official' statement about.
I am developing an application in WPF / .Net 3.5 that will be available for download on the internet. I am - to the best of my ability - writing bug free code, and using exceptions only where necessary. However my experience with software development has shown that users always manage to do something strange which causes an exception to be thrown in a way you could never imagined possible. I would like to gather additional information when I have to catch an unhandled exception. So far I am capturing the following:
Standard Exception fields (message, type, stacktrace etc)
OS Version
.Net version
Versions of the Applications DLLs loaded into the AppDomain
App licence information
Instrumentation of the last few commands executed by the user.
I am very concious that I do not want to capture any 'personal' information about the user as I just don't believe in that sort of thing. Hence not bothering with the username/domain/ip address (although as the exception information is delivered to a webservice I will inherently get ip information but it may be of a proxy machine).
My Question
Anyone who has released an application into the public domain (i.e. onto computers not in a controlled corporate environment) - can you suggest anything else that would be useful in tracking down the causes of errors?
Particularly I do not want to collect information that I cannot manage/code for - I.e. the amount of memory available on the PC, or type of printers attached - These things are handled by the .net framework and I shouldn't really (read: don't want to) have to alter my code to cope with the variations out there!
Thanks!
I think that should be enough. You have information about the environment, what the user was trying to do, and one of the most important debugging tools: the stack trace.
Unless you are talking about a printer management application or something, then printer information would not be worth it.
There is always that remote chance that you will encounter an error that results from a strange combination of hardware, running services, installed applications and moon phase. I don't think it is worth to rabidly collect information about the user environment just to deal with those rare errors.
Just remember to have a way that you can be contacted for bug reports, in case a user really needs his particular problem fixed, so that he can provide more information about it and help you reproduce it. Depending on your target audience you have to decide between something like a bug tracker or a simple e-mail address.