Please help, for the sake of my non-pulled out hair...
The following code line:
this._connectionString = ConfigurationManager.ConnectionStrings["SqlConnectionString"].ConnectionString;
is causing me untold amounts of grief.
It is in a user control, currently in the control's Loaded event but I've also tried the constructor and just plain initializing the field to the value when it's declared. Whenever I do so, the WPF designer pitches a fit on any screen that uses said user control.
The code itself compiles fine, and runs with no issues. But it's turning into a real hampering in development not being able to use the designer at all. Does anyone have any clue what could cause this and a hint as to a good practice to avoid it in the future? I suspect it has something to do with trying to access the ConfigurationManager but I can't figure out where to put the line to make it stop.
Thanks.
PS: Visual Studio 2010 Premium
When you're working in design time, you should avoid loading this. Fill in the value with some other, appropriate default, instead:
if (DesignerProperties.GetIsInDesignMode(this))
this._connectionString = "Default";
else
{
this._connectionString = ConfigurationManager
.ConnectionStrings["SqlConnectionString"]
.ConnectionString;
}
The designer probably isn't looking at your app's configuration but rather at the configuration of its current host app (VS), and so ConfigurationManager.ConnectionStrings["SqlConnectionString"] returns null at design-time.
This restriction is similar to what is see in MVC applications whereby the Web.Config doesn't get instantiated at design time. Lo...WPF does the same thing whereby the App.Config is not present at design time.
Related
I know there are a lot of problems like that and you all might think this is a duplicate but NO... this problem is different.
When I add a custom user control to a project and rebuild it, the control is added to the toolbox. If I try to add another one it does not show up in the toolbox. If I close visual studio and reopen it the first control also was removed from the toolbox and will never appear again. From now on the project is broken and no control added, remove + readded will ever show up in the toolbox. So I create a new project and it starts from the beginning.
Before this tip appears I'll say it: Automatically Populate Toolbox is True. Nothing helps against this problem. Build Project/Solution, Rebuild, Clean+Rebuild, Restart of VS, Restart of Computer, Unload and reload the project, set toolbox back to default. Nothing works.
Any ideas??
You have to remember that the designer call your code constructor and some other methods at design time.
If you build the code and the control does not appears and it has not been hidden by an attribute, then probably the code you wrote is not compatible with the designer. For example, the control might throw an exception in design mode because of incorrect code.
The attribute is [ToolboxItem(false)]. If you have a base class that hide it, it will also be hidden in derived class if not specified otherwise.
You will have the same problem if that control is used in another component. You won't see it if it does not compile and run correctly.
The trick to debug that kind of problem, is to attach a debugger from a second instance of Visual Studio to find where in your code you throw an exception.
If the control does not work at run-time, better to fix that first as if it also fix design problem, it is simpler to debug that way.
Otherwise, you have to ensure that your project dependencies are correct. The toolbox will only shows component from DLLs that are referenced by the current project (or from itself I think).
I have a WPF application which is giving me a very very annoying error
System.Runtime.Remoting.RemotingException
[12068] Designer process terminated unexpectedly!
The number between [] changes each time
The XAML is very simple
<UserControl x:Class="STC.Reports.ReportGenerator.Views.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
</UserControl>
This has wasted me hours and hours
Does anyone know anything that could help?
I cant get any more information than that above
Even though I have told VS to break on these Exceptions it doesnt
I have also tried to attach another VS and that makes no difference
I have repaired my installation of VS (2012 Professional)
I have also updated to Update 3
This is even happening when I create a brand new WPF application
Everything seems fine initially, then VS just hangs and the remoting error occurs
Paul
What kind of message are You getting?
If it is a Messagebox when You try to use designer - it is a known issue since VS2010 as far as I remember. It is frequently caused by a video card or its driver, so the easiest way is trying to update your video driver or use some older version. Sometimes that help.
The other way is not to use built-in designer. As for me, I wite pure xaml and it seems to be more convenient and faster way of development. Or, if You like visual UI - You may use Blend. AFAIK it is a part of VS2012 now.
I had this error occur for all windows/controls in a project, even if they were brand new empty windows. I had a markup extension causing a design-time exception (with no indication of this from Visual Studio) and I would get this designer error if I used the markup extension in any project resource dictionaries.
Old post but might be useful for future developers who run into this kind of problem.
I had this exact behaviour. Turned out to be a problem related to my viewmodel. At runtime everything works, but at design time VS will try to load the viewmodel standalone and things got haywire. My viewmodel depended on some global object which I created elsewhere at application startup. Loading the viewmodel standalone creates a exception since the global object was missing.
Quite easy to detect actualy. Just test your viewmodel by instantiating it yourself from code. If it fails VS won't be able to run the designer as well and as you see VS unfortunately won't tell you what happened.
I've been working on a SL5 app for a few days. I've mostly been using a hard coded dummy data collection when styling my app's view. Everything has been working fine, but now I want to connect it to a dynamic data collection generated by my view model (using the data service technique where you have design time & real data depending on the IsInDesignTool property.
After I cleared out the control of the hard coded data and bound it to a collection in my view model. When I run it in debug mode, I see an unhandled exception being thrown in App.xaml.cs. The exception args don't say exactly what the problem is (it is simply saying "Value does not fall within the expected range" but when I look at the sender I find the following coming from the MainWindow (my app only has a single view): "Out-of-browser specific settings do not affect in-browser applications."
Further, when I try to view the MainWindow in the designer in VS, it doesn't render and instead shows an error (the rendered exception in the designer doesn't have any of my namespaces in it, just things about controls & UIElements).
I'm at a bit of a loss how to troubleshoot this. I didn't set anything for out-of-browser when building the app and since it worked with dummy data collections, why would it suddenly have this issue (seems like if I was using an out-of-browser property it would have shown up before I bound the data to the view).
Tips/pointers?
(sorry for my bad english)
I am not sure on what is happening but I saw the error "Out-of-browser specific..." when I tried to access some specific property only available to OOB while running on browser. The solution was to test if running oob before using the property:
if (Application.Current.IsRunningOutOfBrowser)
{
Application.Current.MainWindow.WindowState = WindowState.Maximized;
}
The other problem possibly is unrelated - and sometimes can be really hard to debug - one thing that helped me is to open another instance of VS and attach it to the one where you are seeing the problem. With this setup, go to your problematic View and change to "design view" - keep an eye on the Output window of the attached VS to see if some meaningful exception is shown.
I had a similar issue.
I did put a Textbox inside kind of Listbox (radPanelBar) and added
HorizontalScrollBarVisibility="Auto" to the Textbox. It seems that the textbox had problems when to show the scrollbar and when not. Adding
ScrollViewer.HorizontalScrollBarVisibility="Disabled" to the Listbox did solve it ( so, no OOB issue at all ).
I'm not entirely sure what the error was, but it wasn't at all realted to OOB. I'm using a data service approach (in design time I programatically build real data, not the Expression Blend sample data, but when not in a design tool, it uses the REST services). I started disabling a lot of things in my dynamic data and slowly added them back. Somewhere along the way my dummy data generation was fouling things up, but SL thought it was an OOB issue.
Snoop allows you to look inside the application and change element properties.
Its a great asset for developers, but can be a security issue in some cases, like when we have users who like to look in places where they shouldn't be looking. Is there a way to do something to block applications like Snoop from "snooping" your application?
And if there is no way to block it, what do you recommend to do to minimize security risks?
Snoop is a utility that allows you browse visual tree of a wpf application and view and change properties. Its very useful when you are trying to debug something and have no idea what is going on. You can find more here.
Thank you.
There actually is a way to detect whether your application is being "snooped" by the snoop program. The solution I will give is not a silver bullet, and if someone really wants to snoop your application, they'd have to modify the snoop source code (it's an open source project).
What snoop actually does is it injects an assembly into your application, and the injected assembly recursively examines your applications visual tree starting at the root. In other words, snoop actually runs inside your application. That being said, the solution is to raise an event when the snoop assembly is injected into your application.
First, you need to subscribe to the assembly-loaded event somewhere in your application (preferably the begginging):
AppDomain.CurrentDomain.AssemblyLoad += new AssemblyLoadEventHandler(CurrentDomain_AssemblyLoad);
Then, you would implement the handler somewhat like this:
void CurrentDomain_AssemblyLoad(object sender, AssemblyLoadEventArgs args)
{
if (args.LoadedAssembly.FullName.StartsWith("ManagedInjector"))
MessageBox.Show("hey you, stop snooping");//and shut down your application.
}
You would probably need to enhance this solution for real silver-bullet solution, but at least this solution will definitely stop the current latest version of snoop being run as is (without the code modified). The better solution would be to check that no external assemblies are being injected into your application.
However, Kent is still right in the fact that a utility like Snoop should not cause any security vulnerabilities since security should not be implemented at the UI level. But at least this shows you how to prevent people from "snooping" your application.
By implementing security properly. If your "security" can be thwarted with a tool like Snoop, then you're doing it wrong.
Suppose there's a command that only certain users can execute. It sounds like the only place you're enforcing this is at the UI level (by disabling the corresponding button, for example). That being the case, you're right - I could easily use Snoop to enable the button and execute the command. But you should be enforcing the security constraints on your server, or perhaps in your command execution logic if you have no server. Basically, security should be implemented as close to the thing you're trying to protect as possible. Security at the UI level is merely for convenience of the user.
Great responses for a very good question,
I want to add an example of the password that should never be saved in your datacontext, as snoop check also the datacontext of the UI, so if you use the right control PasswordBox you will find that you can’t bind the password property, that means even if you snoop the application you can’t get the password as it is not saved in any property
But we found many people who try to create a work around (helpers, behaviors, usercontrol ...) to bind the password, but they forget that snoop can get it like that
So your server should never trust your client , every time it should check the right privilege (as we can sniff the client request using Fiddler for exp then rebuild a custome request to by pass client application security)
I have a Silverlight 3 App that became quite big over the time. So I began to try to break it in several smaler Applications that will be dynamically loaded in my Main Application on demand. But I run into a strange problems with my VS 2008.
When I add a new Silverlight Application project to my solution and copy User Controls from my old Main Application into this new project it happens from time to time (about twice a day) that the XAML files and their code behind files loose their association. When this happens and I try to build the project, the compiler complains that he cannot find all the Ccontrols like buttons, labels etc. in the code behind files that I added to the class in the XAML-file. And the build fails of course.
The only workaround that I found so far is to add another Silverlight Application project and move all the content from the first added project to it. Than everything works fine for a while until the problem occurs again.
But that's not really a solution.
Any Ideas what happens here and what i can do?
Best Regards,
Rocko
I have seen issues like this before when changing the namespaces on controls in silverlight. The issue crops up when you don't change both the namespace on the control class, and the full name of the class in the x:class attribute on the root element of the control.
Not sure if this fits your situation or not, but it's the only time I've run into similar issues.