C#
Archived Posts from this Category
Archived Posts from this Category
Posted by Chris Alcock on 24 Sep 2012 | Tagged as: .NET, ASP.NET, C#, COM Interop, Database, Development, Links, Morning Brew, SysAdmin
Posted by Chris Alcock on 10 Jun 2012 | Tagged as: .NET, ASP.NET, Afternoon Tea, C#, COM Interop, Community, Database, Development, Links, Morning Brew, SysAdmin, Talks / Presentations
It’s been quite a while since the last ‘Afternoon Tea’ post, and there have been quite a lot of significant announcements in the past few weeks, coupled with my being busy at work which has resulted in me building up quite a backlog of links which I really wanted to include in a Morning Brew. This post is my attempt to ‘clear the decks’ and get caught up again, and also provides the perfect excuse to do a link roundup of DDD South West which I had the pleasure of presenting at at the end of last month.
Posted by Chris Alcock on 18 Nov 2009 | Tagged as: .NET, C#, Development, Morning Brew
Posted by Chris Alcock on 30 Oct 2007 | Tagged as: .NET, C#, Design, Development, Software, SysAdmin
One of my longest standing pet hates with desktop software developed in .NET relates to the almost inevitable security exception that will occur if you attempt to run it from a network share. Its always one of the first things I notice about software, as I often download and unzip software onto my desktop (which on my work machine is located on a network share) and then attempt to run it in place. Many large and quite impressive pieces of software that get distributed as .ZIP files rather than installers suffer this plight, and a lot of them don’t handle the exception well (One that springs to mind was the much heralded release of NDepend 2.0).
The good news is that this anguish may well be about to come to an end, as Brad Abrams requests feedback about the .NET teams possible plan to make network shares trusted. As he mentions, there really is no good reason not to trust a network share for running managed .NET code - there is no such protection for unmanaged code, and there is little or no way a normal user would be aware of which is .a NET EXE and which is unmanaged EXE.
To answer Brad’s Questions:
A) Have you ever run into this limitation (a security exception when running a .NET application from a network file share)?
I frequently experience these issues - I tend to use this problem (and if its been worked round in the application) as a yard stick as to how well written the application is.
B) How often do you use network file shares for deploying applications (managed or otherwise)?
Most of my development is web based, however for utilities written for in house use we tend to distribute them on a network share - being able to run these in place would be a great help, as updating them would be easier.
C) If you think we should make this change, when would be a good time? Is it something we should do sooner in a service pack of the .NET Framework or later in a full release of the framework. Note, we are DONE with .NET Framework 3.5, so there is zero chance it is getting in that release.
From my point of view a patch as soon as possible, and have it included in the next release of the framework - Since this is a relaxation of the current restriction, I can’t see that it would cause any more problems in terms of support of existing application, as a reduction of the support incidents caused by this issue would reduce.
D) Can you ask your local network admin what they think of this issue? Would they be in favor of this sort of change? If so, when?
This change should simplify deployment - allowing Managed EXE to run from shares should mean that local disks can be more locked down as there would be no need to copy programs locally to run them.
All in all, I’m very much in favour of this change - It will level the playing field, give a more consistent user experience, and reduce the problems people have with winforms applications.
Posted by Chris Alcock on 01 Oct 2007 | Tagged as: .NET, ASP.NET, C#, Development, Web Services, XML
One of my basic assumptions about the .NET framework was proved incorrect last week. Up until then, I had believed that when you are using the built in framework classes for exposing web services you were always safe when it came to the output being valid XML. Sadly that turns out to be untrue, and to make matters worse, .NET will happily output XML over a web service even its own .NET web service clients can’t read.
There are certain characters that are forbidden from being in XML as per the official specification. These characters are the low ascii characters such as NULL, EOF etc. Its important to note that this is not a case of unescaped/unencoded versions of this character being disallowed, the encoded characters are also disallowed.
The problem with this isn’t that the .NET framework doesn’t understand these rules - it manages just fine when it comes to acting as a client to a web service serving these characters in content, throwing nice exceptions explaining that these characters are invalid. Additionally, the XML Text Reader has a property ‘Normalization’ which causes the XML reader to be more liberal and ignore invalid characters - but this option is not used within the automatically generated Web Service Client.
This problem isn’t limited to just the web services, standard XML serialisation also experiences the same problems. Here are bits of code that illustrate the problem:
[WebMethod()]
public string InvalidCharacter()
{
return "" + (char)4;
}
public class MyClass
{
public string Test = "" + (char)0;
public static void Main()
{
MyClass c = new MyClass();
System.Xml.Serialization.XmlSerializer xs = new System.Xml.Serialization.XmlSerializer(typeof(MyClass));
System.Text.StringBuilder sb = new System.Text.StringBuilder();
System.IO.StringWriter sw = new System.IO.StringWriter(sb);
xs.Serialize(sw, c);
Console.WriteLine(sb.ToString());
System.IO.StringReader sr = new System.IO.StringReader(sb.ToString());
try
{
c = (MyClass)xs.Deserialize(sr);
}
catch (System.Exception ex)
{
Console.WriteLine(ex.ToString());
}
}
}
The little console application gives output like this:
<?xml version="1.0" encoding="utf-16"?>
<MyClass xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Test>�</Test>
</MyClass>
System.InvalidOperationException: There is an error in XML document (3, 12).
System.Xml.XmlException: '.', hexadecimal value 0x00, is an invalid character.
Line 3, position 12.
Unfortunately I haven’t yet found a fix for this - my only solution is to work around the problem by ensuring that these invalid characters can’t get into the system in the first place or clean the text on the get of each property of the serialized objects.
Things like this really worry me - our frameworks shouldn’t be outputting things that they can’t read - let alone outputting things that completely contravene the specifications. As always, any suggestions on an alternative solution to this problem are welcome.
Posted by Chris Alcock on 17 Jun 2007 | Tagged as: .NET, C#, Community, Photography, Software
OK, the time has come to unveil my Hack for Yahoo Hack Day. Face Ball is the ‘Crazy new game at Flickr HQ‘, and images have been popping up all over flickr as other join in. Well now, you too can join in the fun, and just like Thom Shannon, make your own Face Ball images without risk of injury or special equipment.
Flickr Face Ball is a .NET 2 Windows Forms application that allows you to select images from you Flickr photo stream by tagging them as ‘ToFaceBall’, and add one of three different face ball images to the original photo, uploading the results to your Flickr account.
So, how do you get involved in this craze:
Credits:
FlickrFaceBall uses the Flickr.NET API Implementation - I have only good things to say about this library - it just works
Thom Shannon for providing the inspiration for the Hack, and also providing the PSD of face ball images.
Finally, to the original source of the Face Ball images - photo1 and photo2
Please Note: This program is hack quality code - It’s not been tested much, and if it breaks your computer, flickr account, or anything else, its your own responsibility.
Posted by Chris Alcock on 08 Feb 2007 | Tagged as: .NET, C#, Development
One of my pet hates about the default ApplicationSettings within the .NET framework is the inability to work with multiple values for the same key in the config file (app.config or web.Config)
<appSettings>
<add key="key" value="value1" />
<add key="key" value="value2" />
<add key="key" value="value3" />
</appSettings>
The built in support suggests that it would be possible to call the System.Configuration.ConfigurationSettings.AppSettings.GetValues("key") method to return a string[] containing all the values for the specified key. Unfortunately, the built in support only returns the last value defined (in my example above, “value3″)
Thankfully there are a number of very easy to use replacements for the standard support, and a variation on the solution proposed in Diego Mijelshon’s article How to make AppSettings work with multiple values for a key is one of the first things that I add into any application which will make use of AppSettings.
Code Project has a number of good articles about extending the default AppSettings support, two others which caught my eye are:
Posted by Chris Alcock on 06 Feb 2007 | Tagged as: .NET, C#, Development, IIS, SysAdmin, Web Services
Web Services are very simple to consume using .NET code, and its all to easy to forget what is actually going on when you add that Web Reference to your project in Visual Studio. Once you’ve entered the URL for you web service and clicked the Add Reference button, Visual Studio requests the service description WSDL file, and code generates classes to represent the data and the web service methods. I found delving into this generated code taught me quite a lot about the way XML serialization and web services actually work.
Behind the scenes the web service proxy uses classes in the System.Web.Services.Protocols namespace to actually perform the calls to the service, and these calls end up as System.Net.WebRequests containing the correctly encoded data that makes up the message.
Quite a lot of the problems with web services I encounter during deployment are actually problems with the System.Net.WebRequest. The most common cause of problems seems to be problems where web access is provided via some form of HTTP Proxy Server, and this typically results in an exception of the form:
[WebException: The underlying connection was closed: Unable to connect to the remote server.]
If you have access to the machine running your application its a very good idea to check if the machine can make a request to your Web Service endpoint using a web browser. This also allows you to check the settings to see if web traffic is passing through a proxy - failing this, check with the people responsible for the network.
If you find that there is a proxy involved, there are a couple of strategies available to resolve the problem.
machine.config to affect all applicationsdefaultProxy section with that attribute usesystemdefault="false"allow system wide setting of a default proxy server overriding an OS setting:<configuration><system.net><defaultProxy><proxy usesystemdefault = "false"proxyaddress="http://proxyserver:port"bypassonlocal="false"/></defaultProxy></system.net></configuration>
web.config or app.confg files
using System.Net;
MyWebService ws= new MyWebService();
WebProxy proxyObject = new WebProxy("http://proxyservername:port", true);
MyWebService.Proxy = proxyObject;
MyWebService.MyWebMethod();
All of the above methods apply to Web Service classes and also the WebRequest Classes
I discovered this week that the proxy problem is not the only cause of a web application which calls a web service throwing the exception:
[WebException: The underlying connection was closed: Unable to connect to the remote server.]
The next step I took in investigating this problem was to create two very simple test applications - one ASP.NET based like the code I was having problems with, and another a simple console application I could run as Administrator on the machine in question.
Test.aspx
<%@Page language="c#"%>
<%
System.Net.WebRequest r = System.Net.WebRequest.Create("http://av.com");
string resp = new System.IO.StreamReader(r.GetResponse()
.GetResponseStream()).ReadToEnd();
Response.Write("Response:");
Response.Write(resp);
%>
test.cs
using System;
using System.Net;
using System.IO;
public class Test
{
public static void Main()
{
WebRequest r = WebRequest.Create("http://av.com");
string resp = new StreamReader(r.GetResponse().GetResponseStream()).ReadToEnd();
Console.WriteLine("Response:");
Console.WriteLine(resp);
}
}
Both of these make WebRequests to the Altavista search engine, and therefore tested requests out onto the Internet, returning the HTML from the Altavista homepage. As expected the ASP.NET based version gave the same exception as before, however the console application revealed not one, but two exceptions:
Unhandled Exception: System.TypeInitializationException: The type initializer for "System.Net.Sockets.Socket" threw an exception.
---> System.Net.Sockets.SocketException: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full
at System.Net.Sockets.Socket.InitializeSockets()
at System.Net.Sockets.Socket..cctor()
Which is followed by a more standard looking timeout exception
[WebException: The operation has timed-out. ]
Changing the test code to request a page from the local IIS server to no effect confirmed that it was unlikely that this was an HTTP proxy problem.
Quite a lot of searching the web, lead me towards an Microsoft Bulletin Bulletin
BUG: You receive a “The operation has timed-out” error message when you access a Web service or when you use the IPAddress class which sounded somewhat familiar, and suggested that the problem might be caused by have more than 50 protocol bindings . Running the enum.exe utliity linked in the MS article revealed that this machine had over 100 bindings. Performing the same check on a number of other machines revealed that a more typical value was about 20, so something was not quite right with this machine. Removing some unneeded protocols from the networking setup resolved the issue, with both console application and ASP.NET test page returned the expected HTML, and most importantly the failing web service calls in the web application now works.