MSVS 2010 crash on opening project/solution

[DavidWhite]

I am partially through migrating from XP to Win7, and have successfully installed MSVS 2010 SP1 (full version) amd IVF Update 8 on my Win7 machine. As I need to keep the XP machine going for some time, so to comply with the MSVS license, on my XP machine, I uninstalled MSVS 2010 and installed IVF Update 8 complete with MSVS 2010 Shell.

As far as I am aware, this change was succcessful, and I have been able to continue updating and building my applications on the XP machine. However, at least one ofmy solutions (last updated October) repeatedly causes MSVS to crash during loading. The solution has multiple project files included in it. Any ideas how to resolvethis problem, short of creating a new solution from scratch?

Thanks,

David

[IanH]

(If you have a normal "retail" licence of full VS2010 (as opposed to some special volume licensing deal), it is licensed per-user, not per-machine - see top of page 15 in this download.)

[DavidWhite]

Thanks, Ian.

Are you aware whether this is a new policy? I'm sure that before I upgraded from my previous version of MSVS, I was not permitted to have it installed on more than one machine.

Thanks,

David

[Steven_L_Intel1]

As far as I know, that has been Microsoft's policy with most of their products. It depends, I suppose, on what license type you have, but for retail purchasers it is per-system. (Note that Intel's license policy is more permissive.)

Try uninstalling and reinstalling Fortran. I have seen some other reports of this problem but thought that Update 8 solved them.

[IanH]

I don't know if it is new or changed. Both my VS2010 and VS2005 licence agreements state that it is per-user. My editions of VS older than that have been relegated to the shed.

[DavidWhite]

I have now reinstalled MSVS 2010 full version and Update 8. The same Solutiuon file still crashes MSVS. This was working in October when I last rebuilt the application. No changes to the solution have been made since then.

Any ideas?

thanks,

David

[Steven_L_Intel1]

I can reproduce the problem. Let me see what the developers say... Issue ID is DPD200178459.

[DavidWhite]

Steve,

Is there any progress on this issue? I need to rebuild this project within the next few weeks as it contains links to a server which is to be replaced.

Thanks,

David

[DavidWhite]

Steve,

Have found the probable cause of the failure. The file has been corrupted by a file comparison utility. File contained the following.

<<<<<<< .mine

=======

>>>>>>> .r154

Regards,

David

[Steven_L_Intel1]

Ah, so it is. I didn't spot that. I will let the developers know.

[IanH]

Quoting David White

The file has been corrupted by a file comparison utility...

That's subversion's way of telling you where there is an unresolved conflict in a file.

[DavidWhite]

Ian,

I would have expected subversion to report this separately fromthe original file. Unless I copiedthe file back incorrectly?? I did have problems at the time I migrated from XP to Win7 because all of the Program Files entries needed changing, so this could have been the cause.

Thanks,

D

[IanH]

At the time that the conflict was detected (during a commit or upgrade - during your OS migration did you have two working directories on the go at once?) subversion should have complained and given you options for how you wanted to resolve the conflict. What you see in that file is the result of one of those options (the bit immediately after .mine is what was local to your machine when the conflict was detected, the other bit after the "====" is what the repository had), the idea being that you sort things out manually before marking the conflict resolved. For text files that you are directly editing this option (which is probably the default) would be reasonable, not so much for vfproj files that you manipulate indirectly.

(The problem is partly due to the way the integration or VS writes out the XML for the .vfproj file - the closing tag is being put on the same line as one of the elements. When you add (or delete) a file to the project the tag "moves" - so the resulting change covers two lines. If the closing tag was on a separate line the change would simply be the insertion (or deletion) of a single line in the file - which is more consistent with the logical change in project structure that you actually made. Similarly it would be nice it the XML for the vfproj had each attribute for an element on a separate line... )

[DavidWhite]

Thanks, Ian.

It's too long ago now to know what really happened. I checked into the repository on one machine, copied to the new machine and checked out again.

I know at one stage I used grep to find and change all the old folder names (as removing and re-adding all the files in MSVS was too painful).

Regards,

david

[Steven_L_Intel1]

This got fixed a long while ago and I missed updating the thread.