Why does SqlMethods.Like throw NotImplementedException when you try to use it against in memory objects?
It seems like it would be pretty easy to actually implement it with RegEx or something. It's really inconvenient that you can't mock your database to test tricky queries with in memory objects because of this.
Edit: Vote for my feedback!
Friday, January 25, 2008
Misc. Project Notes
First, a minor annoyance: If you happen to have join tables without primary keys defined, the LINQ designer won't generate the properties corresponding to the association. Either go have a talk with your DBA or update the Primary Key property for your Properties in the designer and you'll be fine.
Second, TFS is proving more of a hindrance than a help sometimes. So much of the build setup requires duplicated settings on all clients, rather than being centrally managed. Policies must be installed on all machines, code analysis configurations have to be imported into the solution, etc. It seems like the right way for this to work would be for the TFS server to transparently distribute and install any artifacts required by the project.
Additionally, code analysis is nice, but there's no way to have a check in policy that uses it that only applies to some of the projects in the solution. We'd like to exclude our unit test projects (since [ExpectedException] tests in particular result in unreferenced variable warnings), but it's all or nothing.
The source control piece is definitely nicer than VSS, but really, what isn't? There are a few recurring issues, though. Sometimes opening a solution causes lots of the project files to get checked out, even though there are no changes locally (doing a Compare confirms that all files are identical). The other issue revolves around the vsmdi file used with the testing bits. For some reason this file is included in the solution and checked into source control, even though it contains user-specific information. If you bring up the test list window and pick 3 tests to run, the vsmdi is updated to show this. VS tries to check out the file (which someone invariably already has out), which results in VS checking out the solution and adding a new vsmdi file named solutionname1.vsmdi (followed by solutionname2.vsmdi, etc.). Excluding vsdmi from source control entirely as part of TFS settings gets ignored, excluding the file manually from the solution gets ignored, etc. I'd love a workaround for this problem.
The only other thing that would make things easier is an update for BizTalk 2006 R2 so we can use VS2008 to develop against it and not have to run 2 IDEs (and have custom build steps using the 2005 devenv in our team build).
Despite all that complaining, we still have a pretty clever solution going that uses a ton of cool technologies like LINQ, CI, MSTEST, Rhino Mocks, Watin, Windsor, ASP.NET MVC, WCF, and BizTalk 2006 R2.
Second, TFS is proving more of a hindrance than a help sometimes. So much of the build setup requires duplicated settings on all clients, rather than being centrally managed. Policies must be installed on all machines, code analysis configurations have to be imported into the solution, etc. It seems like the right way for this to work would be for the TFS server to transparently distribute and install any artifacts required by the project.
Additionally, code analysis is nice, but there's no way to have a check in policy that uses it that only applies to some of the projects in the solution. We'd like to exclude our unit test projects (since [ExpectedException] tests in particular result in unreferenced variable warnings), but it's all or nothing.
The source control piece is definitely nicer than VSS, but really, what isn't? There are a few recurring issues, though. Sometimes opening a solution causes lots of the project files to get checked out, even though there are no changes locally (doing a Compare confirms that all files are identical). The other issue revolves around the vsmdi file used with the testing bits. For some reason this file is included in the solution and checked into source control, even though it contains user-specific information. If you bring up the test list window and pick 3 tests to run, the vsmdi is updated to show this. VS tries to check out the file (which someone invariably already has out), which results in VS checking out the solution and adding a new vsmdi file named solutionname1.vsmdi (followed by solutionname2.vsmdi, etc.). Excluding vsdmi from source control entirely as part of TFS settings gets ignored, excluding the file manually from the solution gets ignored, etc. I'd love a workaround for this problem.
The only other thing that would make things easier is an update for BizTalk 2006 R2 so we can use VS2008 to develop against it and not have to run 2 IDEs (and have custom build steps using the 2005 devenv in our team build).
Despite all that complaining, we still have a pretty clever solution going that uses a ton of cool technologies like LINQ, CI, MSTEST, Rhino Mocks, Watin, Windsor, ASP.NET MVC, WCF, and BizTalk 2006 R2.
Subscribe to:
Posts (Atom)