Hi,

Just downloaded the new version (6/7) and when I regenerate my project, the csproj file is created with strange formatting characters in it -- if I compare the new csproj file to any of our historical files using Visual Source Safe's "show differences" feature, the files look like this:

OLD (works):

<VisualStudioProject> <CSHARP ProjectType = "Local" ProductVersion = "7.10.3077" SchemaVersion = "2.0" ProjectGuid = "{8A002103-3B48-4ECE-B197-3DBD22D93B40}"

NEW (does not work when trying to open project in VS.net 2003)

ÿþ<.V.i.s.u.a.l.S.t.u.d.i.o.P.r.o.j.e.c.t.>. . . . . . .<.C.S.H.A.R.P. . . . . . . . . . .P.r.o.j.e.c.t.T.y.p.e. .=. .".L.o.c.a.l.". . . . . . . . . . .P.r.o.d.u.c.t.V.e.r.s.i.o.n. .=. .".7...1.0...3.0.7.7.". . . . . . . . . . .S.c.h.e.m.a.V.e.r.s.i.o.n. .=. .".2...0.". . . . . . . . . . .P.r.o.j.e.c.t.G.u.i.d. .=. .".{.F.7.0.7.1.F.C.F.-.B.9.9.B.-.4.2.0.2.-.B.E.8.9.-.F.8.3.8.5.D.4.B.E.E.E.C.}.".

Please help! I can provide much more info over email if it would be helpful.

Jason

The file is now saved using unicode encoding. It works like a charm here. Is the file stored on a different volume/OS ?

Hi Frans,

LLBL is on C: and the destination is on D:, however both volumes are on the same machine running the same OS (XP Pro).

I think the problem may be related to how unicode is stored in Visual Source Safe (?) -- When I generated the project and opened VS.net, everything was fine. I checked in the file, and at that point any team member who got the csproj file from SourceSafe (including me) received this when trying to open the solution:

Unable to read the project file 'OurFileName.csproj'. The file 'OurFilePath\OurFileName.csproj' is not a valid project file. Error on line 68. Expected 'Build' but found 'SETTINGS'.

I'll look and see if there are any unicode-related options in VSS...

Jason

Ug. Initial searches don't look good. Here is a snippet about VSS enhancements coming with the next release of .Net:

"The one area of Visual Studio that appears not to receive any substantive updates in Whidbey is enterprise support. IT organizations using Visual Source Safe, Microsoft’s source code control system, will have to make do with small improvements (such as support for Unicode)."

Still looking....

J

Oh darn, you're right, I didn't think of that!

Hmm, I'm a little stuck here: some people need the unicode support to have their charset supported in the filenames and vs.net project file. However using unicode will cripple the file in Visual Sourcesafe.

I'll add an option for the encoding to the config files and will revert the change to unicode. People who need the unicode support, can change it in the configuration files or opt for the dialog popup and select it.

Otis wrote:

I'll add an option for the encoding to the config files and will revert the change to unicode. People who need the unicode support, can change it in the configuration files or opt for the dialog popup and select it.

That sounds like a great idea, having it be an option. In the meantime, I have found a workaround. I found this snippet of info online:

========================= Unicode Files Visual SourceSafe cannot handle Unicode files. When a file is first added to SourceSafe, SourceSafe auto-detects whether the file is in text or binary format. If Unicode files are added as text format files, SourceSafe can corrupt them.

To work around this issue, add all Unicode files to SourceSafe as binary format files. You can override the file type auto-detect feature by clicking the Advanced button on the File Add dialog when you are adding a file. If the Unicode file has already been added, you can access the properties of the file in SourceSafe and change the file type to Binary.

=========================

I changed the file type of the .csproj to binary, and so far everything seems to be working. This has at least one drawback, however, which is that since VSS thinks the files are binary, it is not as easy to compare differences between files, which can be a very useful tool to solve problems (I used it to figure out what was happening in this problem, for example).

Thanks for the quick response -- it's definitely the unicode change and SourceSafe's inability to save unicode that caused the problem.

Jason

A fix for this is now available. (you can just download the taskperformers .zip, if you don't need the Oracle bugfix or the sqlserver driver bugfix)

If unicode support is still needed, do this: add <parameter name="encoding" value="unicode"/> to the VS.NET project generator task(s) in the generator config file of choice. Other values supported are: utf7, ascii, bigendianunicode and utf8 which is the default.

This is a temporary solution, in the upcoming GUI updates, a preference setting will be added for encoding for files.