General
General
After reading Scotts post on CSS book recommendations, I want to try to get similiar feedback on SQL Server books. This is one area that I would really like to learn more about. I know enough about SQL server to get me around as I have been working with SQL Server for about 6 years now, but never really got into how to setup and properly configure SQL Server as I have always had the help of a DBA. Now, I have some side projects going on, where I really need to understand SQL Server better. I want to learn more about indexing, performace, security and just basic better server management.
So what book do you recommend and why?
I just came across this review and the screen shots that they shown I have never seen before, so I thought I would share this with everyone:
http://www.extremetech.com/slideshow/0,2394,l=&s=25501&a=126556,00.asp
I think the new alt-tab looks really cool.....
http://www.extremetech.com/slideshow_viewer/0,2393,l=&s=25501&a=126556&po=6,00.asp
We are currently taking our current flagship product which is an illustration system for life insurance companies and doing a complete redesign/rewrite for .Net. In our original system we used Active Reports for the reporting tool and have been fairly happy with it.
Moving forward though we have found that Active Reports.Net actually runs slower than its non .Net version. Our reporting was always the slowest part of our system and we were hoping to figure out ways to speed up our reports, so that news was not promising.
I was curious as to see what others are doing in regards to reporting for their .Net applications. Enterprise solutions such as the new SQL Server reporting tool is not an option as the license and framework must support royalty free distribution to desktops. The output must support PDF, and having an RTF option would be nice.
I just saw Williams post about a bug in Visual Studio and thought I would do a follow up to the article I posted last week about discovering the same bug.
We have an agreement with some local MS consultants who were able to try to get some more information for us. It was recommended to us to follow the Team Development with Visual Studio.net and VSS white paper, as that paper gives us guidelines to avoid these dependency problems. The white paper suggests using project references as much as possible, implement a daily build processes that the assemblies are outputed to, and share that location so developers could pull the assemblies down, or require developers to build the assemblies locally on their machines. These steps are required as it is advised not to check the assemblies into VSS. They also suggestion to break your solutions up to logical groups so that you can create establish your project references. This becomes more and more difficult as you have a project that has 50 projects in it, and this is where we are. Right now the project we are working will end up having quite a number of projects, and we are doing our best to set them up to use project references but there are times where we are going to have to use file references and that is where the common output directory would be very helpful.
We also came up with a different solution that is working out well for us, that I don't believe is mentioned in the whitepaper, and that is to take advantage of the post build event in each project. In projects that we know are going to be referenced by another solution through a file reference, we setup a post build event to do an xcopy of the new dll to this common output directory. We use the following command:
XCOPY "$(TargetPath)" "\CommonAssemblies\" /R/Y
Where the macro $(TargetPath) has the fully qualified path to the dll that you just built. At this point, we do check in the assemblies from our CommonAssemblies folder.
One final thought, while we classify this as a bug, apparently MS does not and they do not have plans to fix this. The reason we were given was because there are workaround for the problem, and the issue results from not implementing VSS best practices.
Not really sure which one is worse..... First some background, and I will try to keep it simple....
I have two projects in a solution, A and B where A references B as a project reference in the same solution. Now, we also have the output for the projects pointing to the same assemblies folder(Server Assemblies below) because there is a third project C that references A&B as a file reference.
In case it helps, here is the folder structure for these projects:
Client
Assemblies
Project C
Server
Assemblies
Two Projects (solution is here)
ProjectA
ProjectB
So now the knowledge base article that shed some light on our problem: http://support.microsoft.com/default.aspx?scid=kb;en-us;313512
Title: BUG: "Could Not Copy Temporary Files to the Output Directory" Error Message When You Build a Solution That Contains Multiple Projects
Cause: This problem may occur when one of the assemblies that you compile is larger than 64 kilobytes (KB) and the following conditions is true: Your solution contains projects that are compiled to the same output folder.
Now, our problem is because we have the output directory of projects A&B pointing to the Server/Assemblies folder and our thought there was it would make our file references from ProjectC easier. We read a VSS article that mentioned not to check in the debug/release folders, but we see a need to check in the assemblies at some point so that projects that do file references can work when you “pull latest”. We want to pull the latest on Server/Assemblies, Client(recursively) and have things run for the projects in the client folder.
What I was wondering though is this, how would others structure their projects and how does it impact your VSS structure and build/development processes?
Thanks