|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
.net 2.0 only error "Ticks must be between DateTime.MinValue.Ticks"Get this error "Ticks must be between DateTime.MinValue.Ticks and DateTime.MaxValue.Ticks" on a web site we built on Visual Studio 2003 ( .net 1.1) but deploying to .net 2.0. It runs ok on .net 1.1 I have seen quite a few posts about this e.g http://groups.google.com/group/microsoft.public.dotnet.framework.remoting/browse_frm/thread/e59d0e1f12d129fb/f60046715a977609?lnk=st&q=Ticks+must+be+between+DateTime.MinValue.Ticks+and+DateTime.MaxValue.Ticks&rnum=1#f60046715a977609 but this and others indicate issue with .net 1.1 to .net 2.0 communication and incompatibility introduced into the DateTime and remoting . However our situation is not this but just our site running totally on ..net 2.0 only. Any solutions/hot fixes/workaounds for this problem. All info welcome. Regards JOhn John H wrote:
Show quote > Hi I encountered this when attempting to run our server software with .NET > > Get this error > "Ticks must be between DateTime.MinValue.Ticks and > DateTime.MaxValue.Ticks" > > on a web site we built on Visual Studio 2003 ( .net 1.1) but deploying > to .net 2.0. > It runs ok on .net 1.1 > > I have seen quite a few posts about this e.g > > http://groups.google.com/group/microsoft.public.dotnet.framework.remoting/browse_frm/thread/e59d0e1f12d129fb/f60046715a977609?lnk=st&q=Ticks+must+be+between+DateTime.MinValue.Ticks+and+DateTime.MaxValue.Ticks&rnum=1#f60046715a977609 > > > but this and others indicate issue with .net 1.1 to .net 2.0 > communication and incompatibility introduced into the DateTime and > remoting . > However our situation is not this but just our site running totally on > .net 2.0 only. > Any solutions/hot fixes/workaounds for this problem. > > All info welcome. > > Regards > JOhn > 2.0 and our client software with .NET 1.1 (but the general error applies in ever so many cases). The issue is that the internal storage of DateTime has changed subtly with .NET 2.0. The top two bits of the internal Int64 are now used to indicated the DateTimeKind (Unspecified = 0, Local = 1, UTC = 2). Most times now in .Net 2.0 will be Local or UTC which puts the Int64 ticks value out of range from .NET 1.1's perspective. My workaround was to force an Unspecified DateTimeKind by performing the following magic when passing a DateTime across my client/server interface: utcDateTimeValue = System::DateTime(UtcDateTimeValue.Ticks); (I deal with UTC DateTime values only in the interface between my client and server so losing the DateTimeKind causes no problems for a .NET 2.0 client). I can't see what justification MS had for fundamentally changing a type like this. Such a change can only be backward compatible and just breaks in the general remoting case. And then they dont list it as a breaking change for .NET 2.0. I think they really dropped the ball with this change. It has such nasty implications for remoting and persistent storage with mixed versions. HTH, Peter Bromley ADInstruments Ltd |
|||||||||||||||||||||||