Our solution is to use an abstract or relative drive letter. We either map or 'subst' a drive letter to a development folder. In our case the root of all development is called 'Home', and we 'subst' S: (as in 'source') to a sub-directory of \Home (this allows for different technologies to all be under \Home). You always work relative from S:. You add files to projects from S:, and you check in and out of CVS or VSS from S: You will always find project, solution, and build files etc. reference S: (relative) and never ever reference C: or D: (absolute).

:confused: I've got a solution with two projects. One project is a DLL that provides services. It contains an User Control that provides a UI to some of these services. The DLL is strong named! Strong naming both a debug and a release version seams a little odd to me. The other project is an applet on which I've placed this User Control. The reference from this project to the other is a 'project' reference. I developed everything in debug - everything worked - life was good. Then I built a release version and life has taken a change for the worse. The first symptom is that the control no longer draw in the designer. Usually I can drop another instance from the toolbox and it will draw. However, sometimes I get the following message box; --------------------------- Microsoft Development Environment --------------------------- The user control 'My.Namespace.MyFunky.UserControl' could not be loaded. Ensure that the library containing the control has been built and a project reference has been made to the library containing the control. If you have changed the name of the user control, close and re-open the control's designer to update the toolbox item. --------------------------- OK --------------------------- I've closed everything and rebuilt everything. The project reference is it to a PDB (not DLL) in \obj\... - probably because it is a 'project' reference. However, that file does NOT exist in \obj\..! It exists in \bin\..! I've removed the project reference and re-added it and no change. Local copies of all the DLL and all dependancies exist in the respective \bin directory! **** Another interesting piece of the puzzle. I've modified the control to look different in Debug and Release modes. The control is NOT display in the designer in either debug or release modes. It does display when running in either mode. Interestingly, it is always the debug version - even in release. **** Prior to this new set of symptoms, when I attempted to drop an instance of the User Control onto my test app, I often ran into the following problem. I never resolved it - just traded it for a new symptom. Perhaps they are related. I have a user control that will not instantiate when I drop it on a form at design time, however, it will create fine at runtime. I do not understand the following error messages that appears both as a message box when I drop the user control, and in the Task window both after dropping it and whenever showing the form in the des

:confused: I've built a Reporting Services Data Processing Extension and a test applet that uses it that works fine, but I get this seamingly erroneous error every time I load either the solution or a Reporting Services project that uses my DP extension. Resolver Following assembly cannot be resolved: Don't resolve this assembly Microsoft.ReportingServices.Interfaces.Version-8.0.242.0, Culture=neutral, PublicKeyToken-89845cdcd8080cc91 Resolved to: Note that both the unresolved assembly name and resolved name/path are empty (null). It also doesn't seam to matter if I cancel, browse to the local DLL, or check the don't resolve box and accept. Everything works fine. Note that the DP Extension is a strong named assembly, but if it is in the solution than it is a project reference. I went months without experienceing this problem. I'm not sure what changes might have triggered it - the only thing I can think of is I started building the release version as well as the debug version.

:confused: I've got a Reporting Services Data Processing Extension that concists of both Report Designer and Reporting Service components. I develop it in a solution that contains a shared DLL, the DP Extension DLL, and a test applet EXE. Everything works fine. I also have a Reporting Service project that consumes the DP Extension. If I open and run the project by itself it to works fine. However, If I try to add this project to my main solution I will get an "Invalid Cast" exception when VS.NET tries to load the project. It will fail to load, and of course their is no other information about the error. Any ideas what this is all about.

:confused: I've got some really weird things happening with menus and the form designer, which I assume are somehow inter-related. I am hoping someone has seen these and figured out what they are; 1) Sometimes, when I drop a ManiMenu from the toolbox into the component tray I get an "Invalid Cast" message box popping up. No other information is available about what the problem is. This problem comes and goes. 2) If I do succeed in getting a ContextMenu or MainMenu into the component tray, selecting it will cause the from to shrink by 20 units. The menu editor simply doesn't work, and attempting to use it only results in the form shrinking. Dropping additional ContextMenus or MainMenus into the component tray does the same thing. 3) If I hand code the ContextMenus & MainMenus into InitializeComponent(), everything works - for a while - then all the code gets deleted. I've resorted to putting it in an InternalInitialize() that I call from the destructors and everything works. I know I'm not supposed to add code to InitializeComponent() - All that is in there is a call to my own routine InteranalInitialize() where I've put my hand coded menus. However, the problem existed before I resorted to hand coding the menus - that was my work around. The end result is I hand code my menus and occasionally have to re-adjust the form height as a result of this shrinkage. The problem remains - I can't edit menus and everytime I try to access a menu the form shrinks. Any ideas anyone? With or without my hand coded menus the problems remain.