I am working on a very complex WPF application. I am getting the following exception and I am having a hard time figuring our where is the problematic resource.:
Any advice as to what is the most effective wat to investigate?
Related
'Lo again,
My Dotfuscation efforts continue! So I'm currently working on obfuscating a reasonable complicated WPF application consisting of ~38 assemblies. Now that I've overcome my performance issues (Speeding up obfuscation process), I've now moved on to testing out the BAML obfuscation capabilities of Dotfuscator v4.10.
Trouble is, it ain't working - the errors (well, warnings) that are generated are all of the same form, for which I can find nothing on the 'net that discusses:
BamlAnalysis flagged something in Data Binding Path: SOMEFIELDNAME in
SOMERESOURCEPATHTOBAML.baml for the following reasons:
Could not resolve, may have to manually exclude.
Anyone come across this and have any insight what the heck it wants me to change?
[EDIT:] Even setting up manual excludes on the properties its complaining about does not remove the warning...and it doesn't appear as if the underlying BAML is altered at all (at least not by visual check via reflector).
[EDIT2:] Also, should state that Dotfuscator is a requirement here, so alternative tools probably won't help me.
You can try using the latest version of Eazfuscator.NET to obfuscate complex WPF applications. XAML renaming is powered by a perfect analyzer which takes bindings, commands and every other aspect of XAML into account to deliver the precise results.
For reference, I am using Blend 4...
I have been experiencing a lot of headaches with the auto-generation of the xmlns:d="http://schemas.microsoft.com/expression/blend/2008" namespace, and the associated "d:LayoutOverrides", etc. I do not want this code, and have to remove it all the time because the other developers I work with do not want it in the code. Is there a way to disable Blend from generating this code? I understand that it is there to help the design process but it is not necessary for me and the benefits are not outweighing the code cleanup costs. Thanks in advance!
If it really is causing problems (my thoughts are that these 'other' developers are not being particularly pragmatic), then just start using VisualStudio to write your XAML.
If the you're using Blend because you're going to be more productive due to having a highly styled UI to build, then these other developers need to see that the benefits by far out weigh the negatives of having the odd little bits of markup that get added (which in turn will make your life easier).
I'm trying to use FluidMoveBehaviour from the Dynamic Layout and Styles presentation at MIX 2010 in combination with MVVM (Caliburn.Micro).
The Master/Detail behavior is what I'm after. It isn't working and I would like to find out what's happening behind the curtains to see why Silverlight is not picking it up.
How can I debug the FluidMoveBehaviour?
Because the FluidMoveBehavior is so encapsulated and because the source code is not available, the only recourse when it is not working as expected is trial and error. Even worse, the feature is conceptually very opaque and the implications of what will happen if you change the settings are not at all clear initially.
Your best hope of getting the master/detail scenario to work (the most complicated one) is to create a very small example, get it working, and gradually reintroduce your code until it is fully integrated.
There are other working examples besides the MIX10 demo. I recommend reading and re-reading Mike Taulty's explanation until the feature is less opaque:
Blend Bits 14: Fluid Movement
Notice how he approaches the problem gradually and with little test programs. That is how to avoid wasting time trying to use a "black box" feature.
Anyway, the promise of "effortless interactivity" might ring rather hollow right about now. It is perhaps a lesson for other behavior developers: how will the clients debug it when it isn't working? The answer: give them the tools, like configurable logging. When it's not working, the silence is unbearable.
What is the best way to do this? I want to get this working with nCover.
I made a run at this and came close... but in the end it didn't really work out for me.
The guy from Test Driven made a template for testing silverlight in nunit. I upgraded this to Silverlight 4.0 then I ran nCover.
The proof of concept worked great... but when I tried it on our actual product things fell apart pretty quick.
Many of our unit tests reference AGcore and others referent GUI objects, which is why I think I kept getting some sort of cross threading error.
I read that SilverUnit may be able to do this sort of thing... but you have to pay 700+ dollars per developer. I wish the guy who wrote that would consider selling it separately.
Oh well... someday maybe I'll see code coverage numbers... not today though :-)
zachary,
Can you provide more detail on "the proof of concept worked great"? NCover is not able to profile Silverlight because it does not support the CLR.
I'm going to write a rather big/complex WinForm application such as Paint.NET, SharpDevelop, etc. I think one of the most important things to build such an application is to structure the project properly to increase maintainability and control the complexity.
So what kind of patterns or practices show I use? Any blog posts, papers, open source projects are welcomed. I'm trying to learn something from SharpDevelop but it's rather huge for me to step into.
PS: I'm an experienced programmer formerly targeting to web developement(asp.net, rails, etc.). So I know some design principles and how to use them when implement business logics. Maybe I really need now is a sample to get started with a WinForm application so that I can realize how to handle the menus, controls and others. I've learnt something about the MVP pattern but still unconfident to start a large/complex application.
For big projects the methodology and the tools you are using are equally as important as the architectural design. You need to set up a source control system (like SVN) from day one. Also, it is very good to have a standard build procedure and perform builds in a daily basis. The build procedure should include running all tests, which you should also put some effort in implementing from the start.
Regarding the structure, I believe the single most important thing is to divide your project into building blocks with mimimal dependecies on each other. This way you will be able to think about one small part of the system at the same time and not have to face the full complexity of it. It will also help delegate some work to a fellow programmer, if you have this chance.
In order to get started, I recommend that you implement first something minimal as quick as possible. Then work to make it better and add functionality. This will keep you motivated as you will have something concrete to work with. It will also help you identify major design flaws and important issues early enough to correct them.
This is a good beginners guide from Microsoft itself:
http://msdn.microsoft.com/en-us/beginner/default.aspx
check the Windows track there.
After mastering basics - and since you are an experienced developer - you can check this book "patterns & practices Application Architecture Guide 2.0" from Microsoft also.
I would imagine that many of the techniques that make for successful web projects will translate to Winforms projects. Start small and grow the application incrementally. Try to keep the entire application building/working while you add features one at a time.