Some months ago I was actively developing a Silverlight designer,about which I posted here.
Lately I found a small irritating bug in the designer and started debugging it. The strange thing was that I was practically unable to do that. The debugger was telling me that no debug symbols had been loaded for my silverlight application. For me this is one of the most annoying errors.
However, I spent some time trying to enable silverlight debugging with no success. I debugged it with MessageBox.Show(); and then forgot about the problem.
Today I found myself another bug and decided that it is time to get deeper into the debugging problem.
So to be sure that you will be able to debug silverlight applications:
1) Be sure to check the option for debugging Silverlight in the hosting Web project.
Web project -> Properties -> Web -> under Debuggers
2) There is a tab Silverlight Applications in web project's properties. You should add your project there.
3) Be sure that your ClientBin (or the folder where your web application expects your silverlight xap-s to reside) folder has the latest .xap packages. If not make sure that after building the silverlight project the result .xap goes there. That can be done with postbuild events.
If nothing of these helps, as it happened with me, read further:
This is a solution for debugging with Firefox:
Here’s how to ensure the VS debugger attaches to the Silverlight app for debugging:
* In Firefox address bar type about:config
* Read the warning, choose your preference to always remind you or not and accept
* In the search bar of the config options now type: npctrl
* You should then see the entry: dom.ipc.plugins.enabled.npctrl.dll
* Change the value from true to false (simply double-clicking will change this for you)
* Restart Firefox
Firefox solution source
BTW there is also some valuable comments under this guy's post.
Vassil Tonev's blog
24.04.2010
Extending the US keyboard layout with some German symbols
Have you ever missed some symbol on your keyboard layout? I have.
I learn now german and I miss the symbols that are not part of the english alphabet.
They are as follows:
ä - U+00e4
Ä - U+00c4
ö - U+00f6
Ö - U+00d6
ü - U+00fc
Ü - U+00dc
ß - U+00df
For generating a keyboard layout you need to download the Microsoft Keyboard Layout Creator.
Start the application and open an existing keyboard that you want to inherit, or create one from scratch. Don't be worry, there is no chance that you screw some of the existing layouts. When you double click on a particular key from the keyboard preview, a form for editing will appear. There you should make the changes.
For the german symbols you should use the codes above. I guess these codes are the Unicode representation of the symbols.
The software gives you the ability to simulate that some of the special (ctrl,shift,caps lock) keys or a combination of them is pressed. Also you can test the keyboard layout that you've just created(Project->Test keyboard layout) by manually writing some of the "new" symbols. Then it is a good thing to Validate the layout(Project->Validate layout). After the validation make sure to fill the properties of your layout(Project->Properties). Finally again from the 'Project' menu build the new layout. A setup will be generated. I've tested a layout on W7, Vista and Windows XP. It works just fine. Except the fact that on Windows XP the combination Left Ctrl + Left Alt + symbol worked only for ä. But this may be due to the specific PC, I don't know. However instead of Left Ctrl + Left Alt you can use AltGr that worked perfect even on XP.
Just to mention: If you don't have a well-grounded reason for checking the last 2 checkboxes on the properties form, my advice is DON'T!
I hope this will be useful for somebody except me.
Enjoy.
Here are some screenshots:


I learn now german and I miss the symbols that are not part of the english alphabet.
They are as follows:
ä - U+00e4
Ä - U+00c4
ö - U+00f6
Ö - U+00d6
ü - U+00fc
Ü - U+00dc
ß - U+00df
For generating a keyboard layout you need to download the Microsoft Keyboard Layout Creator.
Start the application and open an existing keyboard that you want to inherit, or create one from scratch. Don't be worry, there is no chance that you screw some of the existing layouts. When you double click on a particular key from the keyboard preview, a form for editing will appear. There you should make the changes.
For the german symbols you should use the codes above. I guess these codes are the Unicode representation of the symbols.
The software gives you the ability to simulate that some of the special (ctrl,shift,caps lock) keys or a combination of them is pressed. Also you can test the keyboard layout that you've just created(Project->Test keyboard layout) by manually writing some of the "new" symbols. Then it is a good thing to Validate the layout(Project->Validate layout). After the validation make sure to fill the properties of your layout(Project->Properties). Finally again from the 'Project' menu build the new layout. A setup will be generated. I've tested a layout on W7, Vista and Windows XP. It works just fine. Except the fact that on Windows XP the combination Left Ctrl + Left Alt + symbol worked only for ä. But this may be due to the specific PC, I don't know. However instead of Left Ctrl + Left Alt you can use AltGr that worked perfect even on XP.
Just to mention: If you don't have a well-grounded reason for checking the last 2 checkboxes on the properties form, my advice is DON'T!
I hope this will be useful for somebody except me.
Enjoy.
Here are some screenshots:


26.03.2010
Using the Microsoft .NET CodeDom Framework
Recently I learned some CodeDom stuff that I consider worth sharing.
CodeDom is an API,included in .NET Framework, that gives us an object oriented way of dealing with the csc.exe (The C# compiler). Visual studio uses this console application for compiling your projects. CSC.exe accepts a whole bunch of parameters. For instance parameters for the path to output to,path for looking for referenced assemblies, parameter that tells the compiler whether to create a library or an executable and so on. The list is really long. Good thing is that you don't actually need all of the parameters. HERE is a reference for the compiler options. I will mention and explain below just the ones I needed in my case.
My task consisted in creating an API for parsing source code that the user of the system creates and compiling that source code in a separate assembly. After that these assemblies are executed on some events in the system.
Example:Lets say your system logs to the windows event log on error. However some of you clients want to send e-mail on every error in the system. So with the "custom code" approach you can just raise event on error in the system. Then for every client wish you can create separate implementation... you know one for writing to the windows event log, another for sending an e-mail to the system administrator etc. And the last step is hooking these implementations to the event. This is a good way for code injection.
To be honest I didn't came to this architecture alone. My project manager gave me this idea and after I developed it and saw it in action, I should admit that it really rocks.
So lets get down to the nitty gritty.
First of all lets see what kind of input I expect for the source code that is going to be compiled.
Between lines 1 and 8 is the needed information apart from the actual code. There are:
1 - The name of the assembly to be created;
2 - The name of the class ,which name will be used later to create an instance of.
3..8 - List of the assemblies that will be included as referenced assemblies
9..23 - The actual code.
I created a class that represents the raw data above. The class has some properties that I need and I initialize them by passing the raw data to the 'ParseRawSource' method.
Here is finally the actual code for compiling the assembly. There are some key things that are worth of mentioning:
1) Adding a 'lib' param that points to thePathWhereTheReferencedAssembliesReside;
2) Setting the 'CompilerVersion' to 'v3.5';
3) Assigning 'buildOutput' out parameter so that whoever calls the method will get eventual build errors.
I hope this post was interesting and helpful.
Enjoy.
CodeDom is an API,included in .NET Framework, that gives us an object oriented way of dealing with the csc.exe (The C# compiler). Visual studio uses this console application for compiling your projects. CSC.exe accepts a whole bunch of parameters. For instance parameters for the path to output to,path for looking for referenced assemblies, parameter that tells the compiler whether to create a library or an executable and so on. The list is really long. Good thing is that you don't actually need all of the parameters. HERE is a reference for the compiler options. I will mention and explain below just the ones I needed in my case.
My task consisted in creating an API for parsing source code that the user of the system creates and compiling that source code in a separate assembly. After that these assemblies are executed on some events in the system.
Example:Lets say your system logs to the windows event log on error. However some of you clients want to send e-mail on every error in the system. So with the "custom code" approach you can just raise event on error in the system. Then for every client wish you can create separate implementation... you know one for writing to the windows event log, another for sending an e-mail to the system administrator etc. And the last step is hooking these implementations to the event. This is a good way for code injection.
To be honest I didn't came to this architecture alone. My project manager gave me this idea and after I developed it and saw it in action, I should admit that it really rocks.
So lets get down to the nitty gritty.
First of all lets see what kind of input I expect for the source code that is going to be compiled.
1: assemblyName:Test.dll
2: className:TestClass
3: include:System.dll
4: include:System.Core.dll
5: include:System.Xml.dll
6: include:NotFrameworkAssembly1.dll
7: include:NotFrameworkAssembly2.dll
8: include:NotFrameworkAssembly3.dll
9: using System;
10: using NamespaceFrom.NotFrameworkAssembly1;
11: using NamespaceFrom.NotFrameworkAssembly2;
12: using NamespaceFrom.NotFrameworkAssembly3;
13: public class TestClass : SomeBaseClass
14: {
15: public override void Method1FromTheBaseClass()
16: {
17: //TODO Add some code that you can execute later
18: }
19: public override void AnotherMethodFromTheBaseClass()
20: {
21: //TODO: Send e-mail
22: }
23: }
Between lines 1 and 8 is the needed information apart from the actual code. There are:
1 - The name of the assembly to be created;
2 - The name of the class ,which name will be used later to create an instance of.
3..8 - List of the assemblies that will be included as referenced assemblies
9..23 - The actual code.
I created a class that represents the raw data above. The class has some properties that I need and I initialize them by passing the raw data to the 'ParseRawSource' method.
public class AssemblyGenerationInfo
{
public ListReferencedAssemblies { get; set; }
public string SourceCode { get; set; }
public string ClassName { get; set; }
public string AssemblyName { get; set; }
public void ParseRawSource(string inputStr)
{
}
//THE MAJORITY OF THE CODE IS OMITTED
Here is finally the actual code for compiling the assembly. There are some key things that are worth of mentioning:
1) Adding a 'lib' param that points to thePathWhereTheReferencedAssembliesReside;
2) Setting the 'CompilerVersion' to 'v3.5';
3) Assigning 'buildOutput' out parameter so that whoever calls the method will get eventual build errors.
public bool CompileAssembly(AssemblyGenerationInfo agi, out string buildOutput)
{
string outputDirectoryPath = "some path";
string thePathWhereTheReferencedAssembliesReside = "some path";
if (agi == null)
{
buildOutput = string.Format("Code to compile was not provided!");
return false;
}
CompilerParameters parameters = new CompilerParameters(agi.ReferencedAssemblies.ToArray());
parameters.IncludeDebugInformation = false;
parameters.CompilerOptions = string.Format(@"/lib:""{0}""", thePathWhereTheReferencedAssembliesReside);
string fullPathToTheCompiledAssembly = Path.Combine(outputDirectoryPath, agi.AssemblyName);
if (!Directory.Exists(outputDirectoryPath))
{
Directory.CreateDirectory(outputDirectoryPath);
}
parameters.OutputAssembly = fullPathToTheCompiledAssembly;
CSharpCodeProvider csc = new CSharpCodeProvider(new Dictionary() { { "CompilerVersion", "v3.5" } });
CompilerResults results = csc.CompileAssemblyFromSource(parameters, agi.SourceCode);
if (results.Errors.Count == 0)
{
buildOutput = null;
return true;
}
else
{
StringBuilder sb = new StringBuilder();
foreach (CompilerError error in results.Errors)
{
sb.Append(error.ToString() + Environment.NewLine);
}
buildOutput = sb.ToString().TrimEnd();
return false;
}
}
I hope this post was interesting and helpful.
Enjoy.
13.02.2010
Blend 2 and Blend 3
Before starting this post I promise myself to make it short. If you take a look at my last 2 ones you will understand why. So Blend. What can I say? Not much of course. Blend is a designer tool and I pretend to be a developer. However for some reasons I had to use it, because I had no other option. VS2008 has no designer for silverlight. And I think it is a very good product. You can make animations (storyboards in terms of xaml), to move things around, to edit properties and I'm sure many many other things.
Let me first write something about Blend 2. It is not so good. It supports only silverlight 1.1 projects. To open and edit SL 2.0 projects you need to install Blend 2 sp1. But that brings you just the ability to edit SL 2.0 projects. The same problems Blend 2 has are still present in sp1. It can't show inherited forms. Also you can't select a control by clicking it in the designer. Instead you need to find it in the control tree and then select it. And I'm sure Blend 2 has some other bugs too.
Blend 3 is something different. Again I can give a good review because I use maybe less than 10% of its features, but I think it is much better than Blend 2. The problems mentioned above are solved here. Also Blend 3 is in my opinion faster. It loads the projects faster and also working with it is easier.
However both versions of Blend share a huge disadvantage. They can't work with Visual SourceSafe. So the designer we have at the office needs to install Visual Studio just to check out the files she needs to edit. And then to check them in.
That is not right. Microsoft should do something about this.
And to keep the promise I gave myself I stop here.
Let me first write something about Blend 2. It is not so good. It supports only silverlight 1.1 projects. To open and edit SL 2.0 projects you need to install Blend 2 sp1. But that brings you just the ability to edit SL 2.0 projects. The same problems Blend 2 has are still present in sp1. It can't show inherited forms. Also you can't select a control by clicking it in the designer. Instead you need to find it in the control tree and then select it. And I'm sure Blend 2 has some other bugs too.
Blend 3 is something different. Again I can give a good review because I use maybe less than 10% of its features, but I think it is much better than Blend 2. The problems mentioned above are solved here. Also Blend 3 is in my opinion faster. It loads the projects faster and also working with it is easier.
However both versions of Blend share a huge disadvantage. They can't work with Visual SourceSafe. So the designer we have at the office needs to install Visual Studio just to check out the files she needs to edit. And then to check them in.
That is not right. Microsoft should do something about this.
And to keep the promise I gave myself I stop here.
Абонамент за:
Публикации (Atom)