Thursday, 31 May 2012

A Refactoring Experience.

Often when you are faced with a big refactor, removing a property in a class which is used many places in your code, it seems that the quickest way to go about it, is to simply delete the property and correct all the errors that the compiler finds. This poses a problem however, because you will put all your code in a long state of limbo where you change code, and are not able to to compile and test your changes. If you like me is a bit of a test driven developer, it hurts not to be able to see the green bar for hours. Often these changes also drives other changes, which you might start implementing also, pushing your code even further out in no mans land.

A much better way of going about it is to use the IDE common feature “Usages of”, and then go through the each of the refactorings one by one. Depending on how big they are, you can do build->test at different intervals. even check your code in midway, since it is all building and goes green bar.

Wednesday, 8 September 2010

MVC custom error problem on IIS7



From bitter experience I have now learned (once again) how important it is to test your applications in a staging environment which is different from your development machine.

In this case our problem was customErrors, which looks fantastic on your developer machine, but gets thrown away when you install your application in the IIS 7 server.

Luckily I found this guys post:
IIS 7 Error Pages taking over 500 Errors which describes the problem. Only when you use MVC and do some error handling in the controllers, it doesnt arrive to the Application_Error method, as he describes, but instead you should add the "TrySkipIisCustomErrors" in the OnException in each controller.

protected override void OnException(ExceptionContext filterContext)
{
string viewName = "MyErrorView";
System.Web.HttpContext.Current.Response.TrySkipIisCustomErrors = true;
View(viewName, errorData).ExecuteResult(this.ControllerContext);

}

In any case its always good to do something in the Application_Error method, if nothing else, log any errors which is not handled any other places

Wednesday, 30 June 2010

71-515 .NET 4 web application developer

Finaly Microsoft gave me my result of my Beta exam:



I PASSED :D

Visual Studio 2010 cheat sheet

I found the cheat sheet for VS2010: link

Friday, 4 June 2010

adding dates to a filename in a bat script

In case others out there need something so prehistoric as making a bat script which adds a date to a filename for ex when creating a back up with 7-zip.

The following worked for me:

call "c:\Program Files\7-Zip\7z.exe" a -tzip %date:~6,4%-%date:~3,2%-%date:~0,2%.%time:~0,2%-%time:~3,2%-zipFile.zip *.dll


will zip files into an archive called:


2010-06-04.15-37-zipFile.zip


Hope it will save you some frustration!

Thursday, 4 March 2010

Prealoading Web Applications

On the list of what's new in ASP.NET 4.0 you find "Prealoading Web Applications".

If you are running ASP.NET 4.0 on IIS 7.5 you can ask sites to be preloaded when the Internet server starts up (or restarts).

It sounds cool, and a good thing that you are now able to reload heavy services, but I can help thinking that it is also a solution to a problem which should exist. The IIS should handle the Internet communication, while leaving the heavy data processing to services outside of the IIS. These services would should be implemented as services on the server, No?

70-515. TS: Web Applications Development with Microsoft .NET Framework 4

With the announcement of the .NET 4.0 exams, it seems a bit like a wrong career move not to aim for taking the web application development certificate for 4.0 instead of 3.5, since I have already been working with VS2010 for some time now.

Looking at the Skills Being Measured List it seems like a good idea to continue studying the MCTS Self-Paced Training Kit (Exam 70-562) with a sharp eye to the list of topics.

Hopefully I will be invited to take a beta exam when they come out in April.

I guess a good place to start looking into the ASP.NET 4.0 would be here

Here are some of my comments to the elements of What's new:

Tuesday, 9 February 2010

ExecuteScalar doesn't return the return value

One thing to remember when making a stored procedure or just simple SQL, which should be executed thought a call of the ExecuteScalar method in .NET: that ExecuteScalar doesn't actually return the return value but the first column of the first row in the result set, or a null reference if no result is found!

Thursday, 7 January 2010

The skitzofrenic DataRow Versions.

The DataRow contains several different versions (DataRowVersion) of the data it contains and several different RowStates, and of top of that it can be in edit mode or not. This can be a bit complicated grasp, in the following I will try to explain to myself (and any other reader) how it works.

The RowState is a description of the rows connection to a DataTable and whether the data is changed.

The different DataRowVersion contains the different versions of the data, and can either be: Current, Original, Proposed or a pointer to one of the three (it is usually denoted as the Default).

And finally a DataRow can be in Edit Mode or not. A DataRow enters and exits this mode when BeginEdit and EndEdit is invoked respectively.

The lifetime of a DataRow can pass through these RowStates:

  1. Detatched: The DataRow is created but not attached to any DataTable.
  2. Added: The RowState goes to Added when it is added to a DataTable.
  3. Unchanged: If the AcceptChanges method is invoked, the RowState becomes Unchanged.
  4. Modified: If the data is modified the RowState becomes Modified, this is however not true if the current RowState is Added.
  5. Deleted: When the Delete method is invoked.


Strangely enough the DataRowVersions doesnt really have anything to do with the RowState, but whether the DataRow is in Edit Mode or not(or well in RowState Deleted.

Before an Edit the default data in the row is found in Current version. In edit mode the default data will be in the Proposed version, while the current version contains the unedited version.
After an Edit the Original version contains the data from before the edit, while the Current version contains the hmm... current version (in other words the Proposed version in Edit mode).

Thursday, 5 November 2009

SQL update with INNER JOIN

Just a reminder to self:

update ICD
set ICD.if1_deleted = 'Y'
FROM
IF1_FILE as ICD INNER JOIN ID1_FILEDET ON IF1_ID = ID1_PARENT
and ID1_NAME =
and ID1_VALUE = ''

70-536 Passed :)

Friday, 23 October 2009

Reflecting on a Reflection description

I was quite surprised when I arrived at the Reflection chapter in my self training book, because on the first page I found the following:

Reflection is useful anytime you need to examine or run code that isn't available at runtime.

MTS Self-Paced Training Kit (Exam70-536): Microsoft .NET Framework - Application Development Foundation, SECOND EDITION


After I read this, I fear I really need to study Reflection, because the reflection I studied at the university, was exactly the opposite. But I guess just because reflection means something in the Java world doesn't mean that its the same on .NET.

Thursday, 15 October 2009

Code Access Security (CAS)

In the .NET framework all assemblies (which run managed code) is running in their own security scope. Which doesn't just depend on the user running the assembly(in respect to the Role-Based security (RBS)) but also on the Code Access Security (CAS).

The CAS system gathers evidence to identify assemblies to determine which code group the assembly belongs.

Evidence

Evidence is data which the CAS collects at runtime to determined the assembly's security level, like a user is identified by username and password.

Examples of Evidence is:

  1. Applications directory

  2. Hash

  3. Publisher

  4. Site

  5. Strong Name

  6. URL

  7. Zone: The zone in which the assembly is running(Internet Zone, Intranet Zone, or Trusted Zone)


permissions


There is a long list of things an assembly needs to have permission to do, like sending web requests, read or write files ect. for a complete list look here: (System.Security.Permissions Namespace)

A specific example could be the File dialog permission(link), which specifies whether an assembly may present one to the user. Another permission can be File IO which restricts access to files and folders(link)

Permission set


So, this seems pretty straight forward, a permission set is a set of permissions right, it is a so called ACL (Accesss Control List), which means it is a list of permissions, used by the CAS to verify whether it should give permission/access to an assembly.

A well known permission set is the Internet default permission set, which contains the following permissions:

  1. File Dialog

  2. Isolated Storage File

  3. Security

  4. User Interface

  5. Printing


Most are self describing, even if it is worth noting that the Security permission gives the permission to execute, but as with all permissions there are many levels of a permission, look further here SecurityPermissionFlag

.Net framework contains seven default permission sets.

Code group


Based on the evidence, an Assembly is places in a specific code group. A code group is a user groups provided to RBS, its connects the assemblies with permission sets. A group membership condition is determined by one piece evidence which the assembly should have.

An assembly can be member of several groups, if so the assembly will receive the union of the permissions in the permission sets.

Code groups can also be nested inside each other, which allows the manager to make arbitrary complex structures. An example of such a hierarchy is: assemblies with Microsoft strong names is placed in a group called Microsoft_Strong_Name code group, which is contained in My_Computer_Zone code group which again is contained inside All_Code. (in short All_Code->My_Computer_Zone->Microsoft_Strong_Name)


--

Security Policy



Okay so all these things together, should also have a term, so we can make different sets of all these things, and these sets is called a security policy.

A security policy is a logical grouping of code groups and permission sets. The security policy is used to group the security into levels. There are four default security policy levels; Enterprise, machine, User and Application Domain.

Since these overlap an assembly's permission set is the intersection of the policies.

By default, the Enterprise and User security policies grant all code full trust.


Put It All Together


The system administrator can make security policies for the hole network (enterprise security policy), for each computer, for each user, and application domain.

Inside each policy he might look at the different code groups (fx. My_Computer_Zone, LocalIntranet_Zone, Internet_Zone) and check permission set of the groups.

When an assembly is loaded, the system will look at the evidence, and figure out which groups the assembly is in. then all the permissions of these groups are joined, but then you have to take the intersection of the policies, meaning that the policy which is most restrictive sets the permissions. when all this is finished the CAS will compare notes with the RBS of the operation system, and again choose the most restrictive set of permissions. This is also called Security stack walk

Wednesday, 7 October 2009

System.Drawing for backend programmers... hmm

On my quest to become certified microsoft programmer I have arrived at chapter 6 in my self paced training kit for exam 70-536. Which is about drawing graphics. So far I have seen the logic in the topics that every Microsoft certified something should know - reading from files, using different encodings, but drawing graphices, is a bit of a strange topic to put in the basic certificate. Especially when you take it to be allowed to take 70-503 exam which will enable you to call yourself Microsoft Certified Technology Specialist (MCTS) in .NET Framework 3.5, Windows Communication Foundation, which is about communication in distributed systems.

Anyway, now I have just learned to make a jpg file with the following picture:



Which I am sure will come in handy next time I develop a WCF web service, or create a distributed application.

Did it with the following code: (more or less taken from the book)

Bitmap bm = new Bitmap(600, 600);
Graphics g = Graphics.FromImage(bm);

Brush brush = new LinearGradientBrush(new Point(1, 1),
new Point(600, 600),
Color.White, Color.Red);
Point[] points = {
new Point(77,500)
, new Point(590, 100)
, new Point(250, 590)
, new Point(300, 410)
};
g.FillPolygon(brush, points);
bm.Save("bm.jpg", ImageFormat.Jpeg);

Saturday, 3 October 2009

Streams and readers/writers

Finished chapter 2 in the 70-536 training kit book about IO (input/output)

I imagine things like this metaphor: imagine that you have an old tape recorder. You have you tapes and a machine to read it, and record it.

A tape is basically just a stream, which is ready to be read or written in a specific place. The same is the case with the streams in .NET. In the .NET framework is just nice enough to rewind the tapes every time you take out the tape from the machine.

A tape is best used with a reader/writer so to use the stream a reader is created, or to record something a writer is created.

Then there are different kinds of tapes, some are IsolatedFiles which can only be read by your machine.

Wednesday, 30 September 2009

70-536 exam links

A list of links which I found that was interesting for the certificate. (will be updated)


  • Nice friendly blogger who has decided to make a link to a page that describes every aspect of the 70-536 exam link

Sunday, 27 September 2009

WCF service behavior

Unlike the contracts and the addresses a behavior does not always affect both client and server. A behavior can be local and affect only the server sides way of processes the messages.

A behavior is not exposed as part of metadata.

A behavior can either be a service behavior or an endpoint behavior:

Service Behaviors (behaviors which implement IServiceBehavior


A typical service behavior is the debug logging behavior, which is enabled by adding a serviceBehavior in the config file.

Like this:
<behaviors>
<serviceBehaviors>
<behavior name="serviceBehavior">
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>

One thing that is important to remember is to associate the service with this behavoir. like this:

<services>
<service behaviorConfiguration="ServiceBehavior" name="host.HelloIndigoService">
[...]
</service>

Behaviors can of cause also be added programmatically.

Endpoint Behaviors(behaviors which implement IEndpointBehavior



A endpoint behavior is defined in the same way, but here its not associate with a service but with the actual endpoint.

WCF Metadata Exchange (mex)

To my understanding, metadata exchange (in WCF) means whether the service will offer a WSDL or other types of metadata to a client to enable them to autogenerate a proxy for the web services.

By default it is not enabled to exchange metadata, so its something that has to be added as an extra endpoint.

The endpoint works as any other endpoint (see link), where the contract type IMetadataExchange is mandatory. This contract type is a predefined service contract which is found in System.ServiceModel.Description namespace.

The endpoint can have different kinds of bindings like MexHttpBinding (meaning HTTP), MexHttpsBinding (HTTPS)

From a web service perspective it seems a bit strange that you would have to specifically add an endpoint to allow metadata transfer. But since WCF is a general communication framework I'm sure there is lots of places where its better not to have a service sending out metadata.

WCF service endpoint

An endpoint is defined by an address, contract and binding.

A address can be defined in the following ways (in the config file) either as implicit using the base address (which is required to be defined):

<endpoint binding="basicHttpBinding" name="basicHttp" contract="Host.ItecneckService" />

Which would make the service address: "http://localhost:8000/tecneck/"
or as a relative url:

<endpoint address="TecneckService" binding="basicHttpBinding" name="basicHttp" contract="Host.ItecneckService" />

making the url: "http://localhost:8000/tecneck/TecneckService"

or full url:

<endpoint address="http://localhost:8000/tecneck/TecneckService" binding="basicHttpBinding" name="basicHttp" contract="Host.ItecneckService" />

The base address is added like this (under the <service> tag):
<host>
<baseAddresses>
<add baseAddress="http://localhost:8000/tecneck"/>
</baseAddresses>
</host>

A Service can have several endpoints but they have to be unique, and differ in either address, contract or transport protocol. There can be several reasons why a service would have multiple endpoints for example:


  • The service implements several contracts, which could each need their own endpoint

  • More the one protocol should be supported

  • same service must be accessible by clients with different binding requirements, possibly related to security, reliable messaging, or transactions.

Thursday, 17 September 2009

The Pomorodo order

One of the things I have realised after I started using the Pomorodo technique, is that I am very bad at working on one thing at the time. Not working and chatting, or checking emails and so on, but continue and finish working on one task without working on other problems also.

So I set a mark at the task I'm working on, when I start, so I don't get tempted to shift between them :-)