Out apps have to function all over the world from the US East Coast, (where the preponderance of users are), to the west Coast, to Hawaii, to Japan, to the Med and to Afghanistan. Where datetimes are of importance we use zulu time (GMT) . Otherwise we reference the time zone of the system's location and the supporter's location, which Eastern Time, (+5). Time zones were established in the US to accomodate railroads scheduling from the days when each location kept its own time based on Local Apparent Noon. However, they did not really impact most Americans until airline travel and broadcasting. Since most Americans never leave the country all they care about are their own Time zone and Eastern Time (by which the TV shows are scheduled). As far as one time zone for the entire country, I really would not want to work an 8 AM to 4 PM shift and never see the sun. I don't think the pharse "Only mad dogs and Englishmen go out in the Noon day sun" would make much sense, if Noon came before sunrise for most of the year. ;)

No you mention Twilight Zone to these youngsters today and they just stare uncomprehendingly at you.

I have a question that I am sure has been answered many times but I have been unable to find any references on the internet and my attempts to program the situation keep failing and I am running out of time. In designing ASP.Net Web Applications with c# and VB.net I have been able to deploy these applications with only the contents of the bin directory. When I have included third party or in-house class library in the Web app I only needed to include the assembly file (dll) of the class library I am referencing. Now I am trying to analyze alternative designs for a Web service which references a C++ DLL. We want to redesign the DLL as a Visual C++ 2005 DLL, and to reference that assembly in the Web service project. One of the alternatives is to create a visual C++ 2005 ASP.Net web service that references the DLL. I want to report in my evaluation of this alternative that creating a refereence to this Managed assembly of the class library eliminates the need for including the header files in your Web service project. I also want to say that deployment would only require copying the Web service's assembly and the class library's assembly into the bin. (In addtion to the disco, the web config, the asmx, the asax, etc.) But it occured to me I had never actually tested that. Nor had I seen anything written on that. So I tested it first for a c# web service which of course verified my second point. However, when I tested a C++ Web Service I was either unable to successfully compile the Web service, (Error kept reporting the DLL had no copy constructor (which it didn't) when attempting to instantiate object using gcnew: TestDLL::clsPerson^ Me = gcnew TestDLL::clsPerson; or else it would compile successfully but error in the invoke method of the debug when I declared it with out instantiating it. TestDLL::clsPerson^ Me; (note I did not use it at all in the return from the Web service.) At this time I really do not care why it failed I just want an answer to my question. Is it necessary to include the header files from a Managed class library in the Web service when the assembly is referenced using VS 2005 "add reference"? Please help me as this is VERY time sensitive. I need to have this information by Friday 1/12/2007 3:00 PM EST. After that I will have failed in my mandate and it will be of no importance to me as I will be looking for work. Thanks in advance. Edward R. Joell MCSD MCDBA

http://www.deitel.com/books/NET/AddingReferences.pdf Page 4

That was two years ago, I no longer remember were we read it. We were creating an ASP.Net application and we noted that after each build there was a copy of all the dll's we were using in the project's bin directory. We checked in out, and found that this behavior was as designed. Supposedly it was to allieviate the issues of DLL Hell to which the first replier referred to, as the application would always have the the version dll with which that it was compiled to work. The other advantage was that it facilitated the use of XCopy to deploy your application without worrying whether the dll that was needed was registered on the machine to which you were deploying. (The customer liked it because he did not have to register third party dll's on his server.) I found it irritating because I had come from a VB 6.0 background where you only had to set binary compatibility then you could replace the dll without having to re-register it. I ran a google check before answering this entry. But I was not able to locate the place I read it. Could have been a book. Could have been 4GuysFromRolla. Found an entry in MSDN about referencing assemblies. Found a forum entry from a guy that found out the same thing we did. (He asked the question then posted the answer himself when no one answered him.) I am sorry I can't give you a better answer. E.R. Joell MCSD MCDBA

yeah

From original Post: "When I built this application on another machine with VS 2005, the project properties page under Configuration Properties\Debugging had an entry called "Evironment" whereby I could enter the relative path to the YadaYada\bin directory; (Set PATH="..\YadaYada\bin")." I neglected to mentioned that when this was done, everything worked as designed. "But I was not able to find any equivalent entry on the property pages in Visual Studio .Net (2002). I manually added the path to the dll to the machine's "PATH" environment variable but it made no difference. When I copied the dll to the project's folder however everything worked as designed." That was the full path to the specified folder. I tried your #2 and it works. That is what everyone is doing now and I would like to get away from that. I tried your #3 (see above) and it did not work. I tried #1 several weeks ago. I don't remember whether it worked or not. As I recall it required the entry of the path to the dll in the code. However I am trying to avoid that because that would necessitate each developer putting the dll project on their machine in the same location for the code to work. In this non-optimum development environment, each developer uses source safe to get latest version and installs the projects in whatever location they so desire. They then use the VC++ Directories property page to set the linkages to the other header and library files that are needed. They have been copying the dlls into the project directory. Since I am only a contractor for this one project I do not want to tell them to revise their way of doing business. So I was trying to find means by which they could access dlls without copying them into the project directory. Of course this is the .Net solution. (Where the dll's for each name space that is referenced in your project is copied to your bin directory.) I never liked that resolution for dll hell because it requires that any new version of a dll (stuff like bug fixes and service packs), now need to be copied to every application that uses it. For very general reusable code,that is used in many places, (like this is going to be,) that means quite a lot of copying and checking. What about the possibility of using the command line additional options under Configuration\C/C++ folder s of the project property pages? E.R. Joell MCSD MCDBA

"Adding the path to the PATH environment variable is the way to do it but I believe you'll need a full path, not a relative path." Quite right which is what I did. no joy.

I am a long time VB and ASP developer, experienced in both 6.0 and .net. I have had considerable experience in designing COM dll's and .Net class libraries for use by other applications. I am now trying to modularize a complex Visual C++ application by building dll's that can be referenced by different calling applications. Because of the complexity of the code, the short turn aound time and the lack of .Net and COM experience by the other members of the team, this is being done by building a number of Win32 dll's that will then be "plugged into" the calling application. Therefore, I am trying to implicitly link a dll to an executable project using Visual Studio .Net (2002) Visual C++ 7.0. According to Microsoft, the search path used by Windows with implicit linking is 1. the directory where the executable module for the current process is located, 2. the current Directory, 3. the Windows system directory, 4. the Windows directory, and 5. the directories listed in the Path environment variable. The documentation for VS 2002 states the "show directories for Executable files" on the "VC++ Directories" property page, lists the directories that Visual Studio will search for executable files and that it corresponds to the PATH environment variable. I used this property page to link successfully to the library files in the lib directory of the dll project and the header files in the include directory of that project. I used the same means to link to the dll files in the bin directory of that project and I keep getting the "This application has failed to start because yadadyada.dll was not found. Reinstalling the application may fix this problem." message. When I built this application on another machine with VS 2005, the project properties page under Configuration Properties\Debugging had an entry called "Evironment" whereby I could enter the relative path to the YadaYada\bin directory; (Set PATH="..\YadaYada\bin"). But I was not able to find any equivalent entry on the property pages in Visual Studio .Net (2002). I manually added the path to the dll to the machine's "PATH" environment variable but it made no difference. When I copied the dll to the project's folder however everything worked as designed. In my opinion, it is not good practice to include dll's to third party applications directly in your project's directory, (although I know that .Net managed applications do that with referenced third party namespaces). I am also not comfortable with adding third party dll's directly to the system