I have the same problem as you and it's very annoying. So I
made a small change in the source code and rebuild the
project hoping this would help. But I ended up with the "Invalid
OLEVERB structure" message instead.
Has anyone got this task to work with a label and the
recursive attribute set to true?
I'm using
- nant-0.85-rc1
- nantcontrib-0.85-rc1
- VSS 6.0d with latest patch
And where is that SourceSafe.Interop.dll coming from?
Regards
Magnus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've installed that hotfix and yet I still can't get files
out of sourcesafe via the vssget task using a label. I get:
The "path" and/or "version" is not valid.
The way I'm specifying the label for vssget is:
<property name="Module.Label" value="8.1.4" readonly="true" />
and the vssget element looks like
<vssget
username="${vss.username}"
password="${vss.password}"
localpath="${build.dir}\ModuleDir"
recursive="false"
replace="true"
writable="true"
dbpath="${vss.ini}"
path="$\Apps\Module"
version="${Module.Label}"
/>
In the command line help for ss.exe is says you have to
specify the version like -V"label here". I think it looks
for the quotes to differentiate it between labels and
versions. I would expect that the automation api behaves the
same way seeing as it takes an object as an argument to the
call. That being said, how do I set up the Label property so
that it adds the bracketing quotes? I've tried to use &034;
in the hope that it would translate that on the way through
but nant just gets confused and rejects the line. What I
think I should see is that instead of passing 8.1.4 through
the call, it passes "8.1.4" through the call.
Perhaps the original focus of this item was correct in
asking for the Label functionality to be seperated into its
own property and the specific behaviour to Label implemented
there.
Sorry for the ramble
Cheers,
Dan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1227172
I have the same problem as you and it's very annoying. So I
made a small change in the source code and rebuild the
project hoping this would help. But I ended up with the "Invalid
OLEVERB structure" message instead.
Has anyone got this task to work with a label and the
recursive attribute set to true?
I'm using
- nant-0.85-rc1
- nantcontrib-0.85-rc1
- VSS 6.0d with latest patch
And where is that SourceSafe.Interop.dll coming from?
Regards
Magnus
Logged In: YES
user_id=1227172
After much digging it turns out that there is a bug in Visual
Source Safe 6.0d that causes this to fail. Here is a link to
the KB article:
http://support.microsoft.com/default.aspx?scid=kb;en-
us;837417
Unfortunately you have to call PSS to get the code, it is not
available a public download.
/magnus
Logged In: YES
user_id=833138
Use VSS v6.0c
Logged In: YES
user_id=1169386
I've installed that hotfix and yet I still can't get files
out of sourcesafe via the vssget task using a label. I get:
The "path" and/or "version" is not valid.
The way I'm specifying the label for vssget is:
<property name="Module.Label" value="8.1.4" readonly="true" />
and the vssget element looks like
<vssget
username="${vss.username}"
password="${vss.password}"
localpath="${build.dir}\ModuleDir"
recursive="false"
replace="true"
writable="true"
dbpath="${vss.ini}"
path="$\Apps\Module"
version="${Module.Label}"
/>
In the command line help for ss.exe is says you have to
specify the version like -V"label here". I think it looks
for the quotes to differentiate it between labels and
versions. I would expect that the automation api behaves the
same way seeing as it takes an object as an argument to the
call. That being said, how do I set up the Label property so
that it adds the bracketing quotes? I've tried to use &034;
in the hope that it would translate that on the way through
but nant just gets confused and rejects the line. What I
think I should see is that instead of passing 8.1.4 through
the call, it passes "8.1.4" through the call.
Perhaps the original focus of this item was correct in
asking for the Label functionality to be seperated into its
own property and the specific behaviour to Label implemented
there.
Sorry for the ramble
Cheers,
Dan
Logged In: YES
user_id=587960
I have been receiving the same error trying to vssget by
label/version. Has anyone solved or gotten around this problem?
Any info would be greatly appreciated.
Regards,
Brian