> Hello,
>
> I hope there is a solution to this.
It took a few readings to figure out which products you're talking about in
each sentence, but I hope I've understood your question correctly...
> I am required to develop a service application using Visual Studio
> .NET.
VS.NET 2002....
> I am required to develop it using C++.
>
> Originally we set out using Visual Studio .NET 2003. But for the
> database bugs in this framework, this environment supports Windows
> Service project type for the C++ language.
... .NET framework 1.1 that VS.NET 2003 supports. What bugs might these be,
by the way? In general I've found 1.1's database support to be superior to
1.0's support.
> I currently have a solution prepared and (mostly) working but for the
> .NET framework database bugs.
.NET 1.1 framework, that is.
> The application requires Visual Studio .NET and the Service Pack 2 in
> support of key database connection patches.
.NET Framework 1.0 Service Pack 2 and VS.NET 2002.
> Unfortunately there is no Service Pack for VS.NET 2003 or the decision
> would be easy to remain using 2003.
>
> There does not appear to be a Windows Service project available in the
> C++ language?!
... VS.NET 2002.
> Is it easy to add such a project type? Or do I simply start from a
> blank project and copy over any source code that supported the VS.NET
> 2003 solution?
It's not easy to add a project type, but there's nothing magic about project
types - they're simply templates that get you started. Simply copying your
.NET 1.1/VS.NET 2003 solution files into a net .NET 1.0/VS.NET 2002 project
is certainly a good place to start. Since VS.NET 2002 didn't (apparently)
support a Windows Service project type for managed C++, there may be
something that prevents it from working - that I don't know.
You could, of course, build a traditional native Windows Service, using
OLE-DB or ADO or ODBC to access your database and get away from using the
.NET framework at all.
> If necessary I'll use the C# language since this seems to be
> outweighed by framework robustness where database connectivity is
> concerned. And the C# is close enough to C++ to make the migration not
> as painful.
That's certainly another option.
-cd