Checkins to Vault thwarted when attempted via VS.NET 2003

If you are having a problem using Vault, post a message here.

Moderator: SourceGear

Post Reply
jcsteele
Posts: 7
Joined: Wed Nov 23, 2005 4:22 pm

Checkins to Vault thwarted when attempted via VS.NET 2003

Post by jcsteele » Wed Nov 23, 2005 4:42 pm

This may be a common problem but we have just installed FogBugz 4.0 for Windows and are in the process of integrating it with our existing SourceGear Vault v3.1.2 and MS Visual Studio C#.NET 2003v7.1. We have had no problems thus far between FogBugz and Vault. Checkins & checkouts via Vault client seem to be working as advertised with FogBugz in terms of enforcing a valid case id on checkin. However, when our developers have attempted to do the checkins within the VS.NET environment, we get the following error after entering a valid case # on the popup: "You have not entered any valid Bug ID values. A valid Bug ID is required for checkins to this repository." The checkin cannot proceed via VS.NET IDE and we must use the Vault GUI. Is this a Vault or VS.NET configuration issue? Does Vault expect a Dragnet type case number? Any help would be appreciated. Thanks.

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Wed Nov 23, 2005 9:12 pm

This is all controlled by Visual Studio w/ Visual Studio's checkin dialogs.

In order to enter the FogBugz / Dragnet bug IDs, click on the Advanced Toolbar button. You can enter the bug number in that dialog.

HTH
Jeff Clausius
SourceGear

jcsteele
Posts: 7
Joined: Wed Nov 23, 2005 4:22 pm

Checkins thwatred in VS.NET

Post by jcsteele » Fri Nov 25, 2005 4:27 pm

Jeff,
Thanks for the quick response. However, the dialog that comes up as a result of your suggestion is the same one (Update Bugs) that is coming up automatically for us at checkin which is not accepting the case ids we enter. So I get the same "error" blocking the checkin. In VS.NET Tools->Options... there is a folder called Source Control. We have ours set to Visual SourceSafe (even though we are using SourceGear). Is there anything under this folder that we might need to adjust? Or in the General or SCC Provider subfolders? Under General we have nothing checked and "Prompt for checkout" for both drop downs.

Thanks again.

Jeff S.

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Re: Checkins thwatred in VS.NET

Post by jclausius » Fri Nov 25, 2005 8:29 pm

jcsteele wrote:We have ours set to Visual SourceSafe (even though we are using SourceGear). Is there anything under this folder that we might need to adjust? Or in the General or SCC Provider subfolders? Under General we have nothing checked and "Prompt for checkout" for both drop downs.
I have my settings at "Custom", although I don't think using "Visual SourceSafe" would hurt.

Can you check the Repository Options within the Vault Admin Tool? Double check the Bug Tracking App is set to FogBugz and the Bug Tracking URL is correct.

Additionally, you could try "unchecking" the Require Bug ID for Checkins, and try to update a few bugs. If the FogBugz item is not being updated on checkin, then it could be the URL used to interop with FogBugz is incorrect.
Jeff Clausius
SourceGear

jcsteele
Posts: 7
Joined: Wed Nov 23, 2005 4:22 pm

Checkins thwarted using VS.NET

Post by jcsteele » Mon Nov 28, 2005 7:22 am

Jeff,

Our Repository Options in the Admin Tool appear correct. FogBugz is selected and the URL is accurate. Again, FogBugz/Vault integration is working so I don't believe there is a misconfiguration in that area. When checkins are done via Vault we see the files being listed in the FogBugz cases. So I'm unclear about what is learned if I uncheck the "Require Bug ID for checkins" as you suggested if the URL is used between FogBugz and Vault. I tried changing from Use Visual SourceSafe to Use Custom Settings in VS.NET options but when I reaccess the options screen the selection is set back to SourceSafe so that change is not "taking".

mskrobul
Posts: 490
Joined: Wed Jan 14, 2004 10:22 am
Location: SourceGear
Contact:

Post by mskrobul » Mon Nov 28, 2005 9:36 am

There was a bug (that was fixed in Vault 3.1.3) that caused bug validation for Fogbugz to always fail in the IDE. If you are using a version of Vault prior to 3.1.3, you should upgrade to the current version.

Or you can turn off the "Require bug ID for checkin" option in the Admin Tool. The bugs should be updated if you uncheck this option since the validation check that was causing the problems with the IDE only occurred if you have this option on.
Mary Jo Skrobul
SourceGear

jcsteele
Posts: 7
Joined: Wed Nov 23, 2005 4:22 pm

Post by jcsteele » Mon Nov 28, 2005 11:09 am

Thanks, Mary Jo. Since we're currently using Vault 3.1.2 an Vault client upgrade seems to be the thing to try next. I'll post back our results when we complete the upgrade.

jcsteele
Posts: 7
Joined: Wed Nov 23, 2005 4:22 pm

VS.NET thwarts checkins

Post by jcsteele » Mon Nov 28, 2005 3:17 pm

I upgraded my Vault client to 3.1.5 and the checkins proceed without error from VS.NET IDE now. So thank you. My only concern is that now we get a warning/alert under the Vault Messages area stating: "Version Check: SourceGear recommends that the client and server be the same version". Our server version is 3.1.2.3511. Upgrading our server requires more red tape since it is not directly under our control. Is it strongly recommended or necessary that we upgrade? Thanks.

mskrobul
Posts: 490
Joined: Wed Jan 14, 2004 10:22 am
Location: SourceGear
Contact:

Post by mskrobul » Mon Nov 28, 2005 3:33 pm

Of course it is always *recommended* that the Server and the Client are the same version, but a 3.1.2 server will work fine with 3.1.5 clients so there shouldn't be an urgent need to upgrade your server.

If you want to turn off the warning you can do it in the client options (tools->options->general).
Mary Jo Skrobul
SourceGear

jcsteele
Posts: 7
Joined: Wed Nov 23, 2005 4:22 pm

VS.NET thwarts checkins

Post by jcsteele » Mon Nov 28, 2005 3:49 pm

Thanks very much, Mary Jo. I believe our issue has been fully addressed.

Post Reply