Showing posts with label VisualStudio. Show all posts
Showing posts with label VisualStudio. Show all posts

Sunday, January 31, 2010

Using log4net with .Net 4.0 WPF Applications

I ran into some issues trying to get log4net up and running on my current project, which is being written in VS2010 Beta2, targeting the .net 4.0 framework.  I went about adding a reference to log4net, setup my app.config with a rolling log-file appender and added a call to XmlConfigurator.Configure() in one of my classes.

I then went to compile and got the following error: The type or namespace name 'log4net' could not be found (are you missing a using directive or an assembly reference?) 

I double-checked, and yes, I had indeed added a reference to log4net, so what was wrong?  Turns out, for .net 4.0 WPF projects, the default Target Framework is the “.Net Framework 4 Client Profile”, which is a subset of the full framework with the goal of shrinking footprint of the .net framework needed to download for a typical windows application.  However, log4net apparently needs access to system.web.dll, which isn’t included in the client profile. 

To fix your app so it’ll compile/run, open your project’s properties page, and set the Target Framework to “.Net Framework 4” and save your changes. 

Saturday, January 30, 2010

Entity Framework v4 Object-Graph Deleting Quirks

Update: Danny was quick to respond with a great explanation about how EF4 deals with object-graphs and deletes.

I’ve been getting up to speed on Entity Framework V4 (EF4) lately, for use in a WPF application that I’m working on.   One of the issues I’m coming up against is removal of objects in one-to-many and many-to-many relationships.  It’s still not clear to me why things work the way they do in EF4, but I’ll lay out a few scenarios and talk about what works and what doesn’t work and hope that someone can later comment as to why things may not be working as I would expect.

Scenario 1: A many-to-many relationship where the join table has its own primary key (an identity column in this case):

image

Given the following code, I’d expect to be able to remove an object from the Employee.ProjectAssignments collection and see that object removed from the database when I call SaveChanges on my ObjectContext:

using (var context = new EFTestDBEntities()){
                var employeeGraph = (from e in context.Employees.Include("ProjectAssignments").Include("ProjectAssignments.Project") where e.ID == employeeID select e).FirstOrDefault();
                if (employeeGraph != null){
                    var assignment = employeeGraph.ProjectAssignments.First();
                    employeeGraph.ProjectAssignments.Remove(assignment);

                    context.SaveChanges();
                }
            }

When I hit the “SaveChanges()” call, I get the following exception:

System.InvalidOperationException: The operation failed: The relationship could not be changed because one or more of the foreign-key properties is non-nullable. When a change is made to a relationship, the related foreign-key property is set to a null value. If the foreign-key does not support null values, a new relationship must be defined, the foreign-key property must be assigned another non-null value, or the unrelated object must be deleted.

This strikes me as strange – I assume that I’ve indicated that the employee is no longer related to this project-assignment, so the object is essentially “worthless” and I’d expect it to be removed.

In order to successfully remove this project-assignment, I had to do the following:

using (var context = new EFTestDBEntities()){
                var employeeGraph = (from e in context.Employees.Include("ProjectAssignments").Include("ProjectAssignments.Project") where e.ID == employeeID select e).FirstOrDefault();
                if (employeeGraph != null){
                    ProjectAssignment assignment = employeeGraph.ProjectAssignments.First();
                    context.ProjectAssignments.DeleteObject(assignment);

                    context.SaveChanges();
                    Assert.AreEqual(0, employeeGraph.ProjectAssignments.Count);
                }
            }

Okay, so if I “manually” delete the object by the explicit call to DeleteObject, things work.  So far so good, I can work with this.

Scenario 2: A many-to-many relationship where the join table has a primary key that is composed by foreign-keys to the tables on either side of the relationship:

image 

In this case, the code I’d expect to work, actually worked and allowed me to delete a class-schedule from a teacher:

using (var context = new EFTestDBEntities()){
                var teacherGraph = (from t in context.Teachers.Include("ClassSchedules").Include("ClassSchedules.Class") where t.ID == teacherID select t).FirstOrDefault();
                if(teacherGraph != null){
                    var classSchedule = teacherGraph.ClassSchedules.First();
                    teacherGraph.ClassSchedules.Remove(classSchedule);

                    context.SaveChanges();
                }
            }

Why does EF4 make a distinction in behavior between these two scenarios that are essentially the same operation yet one object-graph allows me to write what I naturally want to write (scenario 2), but not the other?

Scenario 3: A one-to-many relationship:

image

Once again, I tried to write the code in a way I’d expect to naturally work:

using (var context = new EFTestDBEntities()){
                var orderGraph = (from o in context.Orders.Include("OrderDetails") where o.ID == orderID select o).FirstOrDefault();
                if(orderGraph != null){
                    var detail = orderGraph.OrderDetails.First();
                    orderGraph.OrderDetails.Remove(detail);

                    context.SaveChanges();
                }
            }

And once again, I got the following exception:

System.InvalidOperationException: The operation failed: The relationship could not be changed because one or more of the foreign-key properties is non-nullable. When a change is made to a relationship, the related foreign-key property is set to a null value. If the foreign-key does not support null values, a new relationship must be defined, the foreign-key property must be assigned another non-null value, or the unrelated object must be deleted.

As with scenario 1, I had to write the following code to successfully remove the OrderDetail record:

using (var context = new EFTestDBEntities()){
                var orderGraph = (from o in context.Orders.Include("OrderDetails") where o.ID == orderID select o).FirstOrDefault();
                if (orderGraph != null){
                    var detail = orderGraph.OrderDetails.First();
                    context.OrderDetails.DeleteObject(detail);

                    context.SaveChanges();
                }
            }

Alright, so I have managed to work around some of the quirks with EF4, but I really don’t understand why removal of objects in the object-graph don’t cause a proper remove/delete in some cases, yet work just as I expect in others. 

Saturday, March 07, 2009

Managing Environment Specific Configurations Settings at Install Time

I’ve been asked a few times in the past few weeks about approaches for managing environment specific settings in config files.  Over the years, I’ve seen this solved a few different ways, and I tend to like the following approach:

  • Create a Setup project in your solution.
  • Open the User Interface Editor, and add a 3-button dialog to the setup (right-click the Start folder and choose “Add Dialog” and pick the 3-button dialog option)
  • Right-Click the newly added entry in the “Start” windows tree and select “Move Up”, so that this window is somewhere before the “Conform Install” dialog.
  • Edit the Properties Window for the 3-buttons window to be something like the following:

SetupProject3Buttons

  • In your main project (UI, Console, etc), add an XML file for the environment specific settings.  The schema should be something like the following:

<environments>
  <
environment name="Development">
    <
setting settingKeyPath="<your xpath here..>" propertyName="<your property here..>" propertyValue="<your value here…>" />
  </
environment>
…….repeat the environment section for each targeted environment

</environments>

  • In your main project, add a new class and have it implement the “Installer” class (found in System.Configuration.Install – so you’ll probably need to add a project reference to that assembly).
  • Override OnAfterInstall, but make sure you first call base.OnAfterInstall(), then start the process of applying your settings from the XML file created earlier to the config file of your installing application.
  • Your environment setting can be pulled from Context.Parameters[“ENVIRONMENT”]
  • Write yourself some code to read in the data in the XML file, and overwrite the appropriate settings in the config file.

That’s the basic steps I take to manage environment specific config file settings in my VisualStudio projects.

VS2008 Database Project Deployment Script Failures

On my current project, we’re using a database project to allow us to manage our schema changes. This has helped us keep all of our dev and build boxes in sync, and things are moving along smoothly.

However, there is one quirk that seems to burn me every few weeks. When we have a script failure, I scan through the output window to see where things went wrong. The IDE is even nice enough to let you click through to the failing line so you can figure out where things went wrong.

That’s nice and all, but the script that gets opened is the deployment script, not the actual .sql file that you created earlier. So, I end up making the change and rebuild/deploy only to get the same error, again. By now, when I review the output and realize what I did, I locate the actual post-deployment script file and make my edits there, rebuild/deploy and things work just fine.

How difficult would it have been to make the generated deployment script read-only so I wouldn’t keep getting burned by this quirk? Better yet, why not take me to the actual script file that caused the problem in the first place?