vbproj files won't update due to read-only locks
Moderator: SourceGear
Thanks for looking into this Jeff, it happens pretty consistent now. My other dev opens the solution which changes 3-4 vbproj files as project references are updated. I just opened the solution, I see the hourglass symbol on the 3-4 projects so I do a GET LATEST on the solution. I then did a Build...Rebuild Solution and got the error as it was trying to save the changed files.
The problem seems to be one of two things:
Doing a Get Latest is not checking out the files being updated so when you attempt a save which occurs (for me) on a Build, it cannot save as the files are still tagged as read-only.
or
Get Latest is performing file edits but is not clearing the read-only file attribute on affected files.
I'm using Vista x64 Ultimate - if it matters.
The problem seems to be one of two things:
Doing a Get Latest is not checking out the files being updated so when you attempt a save which occurs (for me) on a Build, it cannot save as the files are still tagged as read-only.
or
Get Latest is performing file edits but is not clearing the read-only file attribute on affected files.
I'm using Vista x64 Ultimate - if it matters.
Neal Culiner
NC Software, Inc.
http://www.nc-software.com
Vault 5.1.2
VS 2010/C#
Windows 7 Ultimate x64
VB.NET Forums: http://www.vbdotnetforums.com
NC Software, Inc.
http://www.nc-software.com
Vault 5.1.2
VS 2010/C#
Windows 7 Ultimate x64
VB.NET Forums: http://www.vbdotnetforums.com
Jeff,
Duplicating this issue should not be hard.
1) Create a VB.NET solution (Windows App) that has a main EXE and 3-4 Class Libraries. I'll assume you will have your working folder on the C drive. The main EXE should use PROJECT references to the class libraries
2) On another machine set the working folder to a different drive/path combination such as D:\Test\*
3) Open up the solution on one machine and make a few changes, the .vbproj files should also update behind the scenes as the PROJECT references will have to update to the different path
4) Check-in and close the solution
5) On the other machine open up VS.NET 2005 and right-click on the solution node and do a get latest. You can probably trigger the error now by clicking the Save All option or performing a Build...Rebuild Solution, etc.
Duplicating this issue should not be hard.
1) Create a VB.NET solution (Windows App) that has a main EXE and 3-4 Class Libraries. I'll assume you will have your working folder on the C drive. The main EXE should use PROJECT references to the class libraries
2) On another machine set the working folder to a different drive/path combination such as D:\Test\*
3) Open up the solution on one machine and make a few changes, the .vbproj files should also update behind the scenes as the PROJECT references will have to update to the different path
4) Check-in and close the solution
5) On the other machine open up VS.NET 2005 and right-click on the solution node and do a get latest. You can probably trigger the error now by clicking the Save All option or performing a Build...Rebuild Solution, etc.
Neal Culiner
NC Software, Inc.
http://www.nc-software.com
Vault 5.1.2
VS 2010/C#
Windows 7 Ultimate x64
VB.NET Forums: http://www.vbdotnetforums.com
NC Software, Inc.
http://www.nc-software.com
Vault 5.1.2
VS 2010/C#
Windows 7 Ultimate x64
VB.NET Forums: http://www.vbdotnetforums.com
Jeff,
What may help us is by not having our local files set to "read-only" until this issue is fixed. What setttings do we need to change?
In the two attachments, I do not understand these settings. The labels and the corresponding settings just don't make sense and the docs don't tell me much. Can you please explain what these settings mean and their corresponding options?
Thx
What may help us is by not having our local files set to "read-only" until this issue is fixed. What setttings do we need to change?
In the two attachments, I do not understand these settings. The labels and the corresponding settings just don't make sense and the docs don't tell me much. Can you please explain what these settings mean and their corresponding options?
Thx
- Attachments
-
- Vault-MakeWritable.jpg (69.83 KiB) Viewed 3966 times
-
- Vault-MakeWritable-2.jpg (68.93 KiB) Viewed 3966 times
Neal Culiner
NC Software, Inc.
http://www.nc-software.com
Vault 5.1.2
VS 2010/C#
Windows 7 Ultimate x64
VB.NET Forums: http://www.vbdotnetforums.com
NC Software, Inc.
http://www.nc-software.com
Vault 5.1.2
VS 2010/C#
Windows 7 Ultimate x64
VB.NET Forums: http://www.vbdotnetforums.com
I have this problem also
Hi, we are experiencing this problem also. Is this fixed in 4.0.6??
Also can you please clarify the workaround for this?
Cheers
Also can you please clarify the workaround for this?
Cheers
Neal, sorry for the late response, I didn't see you had updated this thread.neal007 wrote:In the two attachments, I do not understand these settings. The labels and the corresponding settings just don't make sense and the docs don't tell me much. Can you please explain what these settings mean and their corresponding options?
Thx
In any case, the "Make Writable" option is not labeled very well, but the Help in the Local Files section explains the value. (Note, it is the same option, just presented in two different places). This option controls the setting used with a GET operation. You can see this in action by making sure your GET command dialog comes up in the Vault GUI client, and looking at the option. So when a GET is invoked, you can make it so all binary files are read only, all files are read-only, or all files are writable.
Jeff Clausius
SourceGear
SourceGear
Re: I have this problem also
This will be fixed in Vault 4.0.7. There was a quick 4.0.6 release which addressed an issue causing "Critical Error in the application" for the server. We had to patch this quickly and issue an unscheduled maintenance release.grant_hot wrote:Hi, we are experiencing this problem also. Is this fixed in 4.0.6??
Also can you please clarify the workaround for this?
Cheers
The issue will be looked at in the scheduled 4.0.7 which is looking like sometime in February.
Jeff Clausius
SourceGear
SourceGear