Hi all,
I'm working on a new project that is in .net 3.5.
Currently the client is using stored procs and we would really like to use LINQ to SQL instead. The main reason they use stored procs is because they believe they are easier to update and such, they dont use any special permissions or such that I can see justify the use of stored procs over LINQ to SQL just they dont want to change.
I figure if I can present them a solution whereby they can easily deploy changes to the LINQ to SQL they might be more open to changing their mind.
As such I'm curious with an asp.net project (not mvc) how to go about updating the various assemblies that get created during the build process.
Say for instance all of my LINQ code is in a System.DataAccess project and that gets deployed to production, a prod bug then gets identified with the LINQ. How difficult is it to just deploy the changed DataAccess project (or rather any project that has had significant changes since the prod deployment).
One thing I'm not sure that will help the situation is that everytime there is a build the build number gets updated on all of the projects regardless of whether there was actually changes or not so just by looking at the version number of the projects would not be enough to determine the projects that need to be redeployed.
I'm not even sure if its possible to modify a build so only the changed projects have their version updated?
So basically I'm just curious as to the various patching processes out there and pros and cons (ie. requires iis reset etc).
Cheers