-
Is Z: a local drive or a network drive? For some reason, it only works if the drive letter is for a local drive. This seems to be a SourceSafe automation problem, not a HippoNet problem. You must use a drive that is local to the SourceSafe server.
I looked into this a while ago, but I couldn't find a workaround. If I do find something, I'll post the solution.
2004-07-28 13:03:55 UTC in Hippo.NET
-
Is \\192.168.9.53 local to your machine? The SourceSafe Automation object that Hippo uses will only work on a local drive.
2004-07-27 20:59:14 UTC in Hippo.NET
-
First, check the hippo.client.exe.config file. That should be in the same directory as your hippo.client.exe. The entry must point to the server where the hippo server is installed. The project name following the slash in the URL must match the project name in the projects.xml file.
Another thing to check is that the path to your nant.exe file is in your system path
Here is a breakdown...
2004-04-22 03:23:57 UTC in Hippo.NET
-
As a test, are you running the client and the server piece on the same machine. More informative error messages are produced when the Hippo client is run from the same machine as the server. It sounds like there might be a problem in the project.xml file configuration. Perhaps one of the entries is pointing to an invalid location.
I have installed Hippo for my team and use it regularly...
2004-04-19 16:02:49 UTC in Hippo.NET
-
After experimenting with different Hippo configurations, what I have found out is that the working directory setting must be on a local drive relative to the Hippo server. This appears to be a windows or SourceSafe limitation. I'm not exactly sure why this is and I need to research it some more (when I can find the time).
However, there is might be a workaround. The nAnt build file could...
2004-03-11 14:00:16 UTC in Hippo.NET
-
HippoNet will download the source code to the working directory specified in the projects.xml configuration file in the 'Server' directory. When I go into SourceSafe, I am able to select network drives as long as they are mapped. I haven't tried this exact scenario in HippoNet but it should work the same since HippoNet just runs SourceSafe automation. I'll try it tonight or tommorow and let...
2004-03-10 22:21:32 UTC in Hippo.NET
-
HippoNet invokes SourceSafe, so if SourceSafe does not allow this then HippoNet won't either. I believe that HippoNet must be on the same server as the VSS database. However, I don't believe that it needs to be on the server where the code will be compiled to. As long as the target server has been mapped, you should be able to set up HippoNet to copy the source files from the VSS server to...
2004-03-10 18:42:40 UTC in Hippo.NET
-
I was able to solve this one also.
By default, Remoting service objects have a lifetime of 5 minutes without any client access. This can be changed by overriding the InitializeLifeTimeService method of the MarshallByRefObject class in the RemoteControl Class. The lifetime can be changed to a different value or it can be made for the entire lifetime of the service by overriding the...
2003-10-27 16:04:07 UTC in Hippo.NET
-
The solution that I gave for Multiple Projects causes another problem. That solution was to remove the shared keyword from the RemoteControl attributes (not _ServerState). This allowed multiple projects to be correctly supported.
However, the ProjectConfiguration objects which exist under RemoteControl.Server seem to have a life of around five minutes if a client window is not open...
2003-10-24 20:51:05 UTC in Hippo.NET
-
See my response to the multiple projects post for the correction to this problem.
2003-10-20 21:24:02 UTC in Hippo.NET
