Context
I'm developing a Microsoft Visual Studio extension, for which I've seen there are:
$projectname$ variable to get the name given to the project,
$safeprojectname$ variable to get the name given to the project with all unsafe characters and spaces replaced by underscore.
Source: https://learn.microsoft.com/en-us/visualstudio/ide/template-parameters?view=vs-2019
For example with project name "Tata yoyo" variables will be:
$projectname$ = "Tata Yoyo SWIG",
$safeprojectname$ = "Tata_Yoyo_SWIG".
The extension I'm building is for SWIG projects that will generate Java from C++, and in this context there is a swig.exe call that, among others, takes the Java package as parameter, for which I want it to be all lower case, but for now it is com.company.$safeprojectname$, then, not necessarily lower case (pointing the obvious: if project name is not lower case, package will not be lower case) and I then have to convert it manually to lower case.
What I'm looking for
From source page above (and other documentation pages) I've already seen there is no $lowercasesafeprojectname$ for example, then if anybody knows a way to do it from a function, script or any other way I would be glad.
Edit: while I want for this purpose a lower case safe project name I still want to keep the original $safeprojectname$, then even if #Ed Dore answer is relevant it is not the solution for me.
In any case, do not hesitate if this is not clear or you want more information.
Thanks
If you implement a custom wizard (IWizard) with your template, you can replace the respective token values in the ReplacementsDictionary passed to your IWizard.RunStarted method, with lowercased equivalents.
Sincerely,
I'm trying to write a query that will return all issues where the set of fixed version(s) is not the same as the set of affected version(s).
The naive solution of affectedVersion = fixVersion fails with:
The value 'fixVersion' does not exist for the field 'affectedVersion'.
Trying to use 'is' fails as well.
How can I do this? I'm willing to install any extra plugins if required, but I'm hoping there's just syntax that I dont know.
It's definitely not possible with Jira out of the box. See the documentation on "Advanced Searching" where it says "Be aware that it is not possible to compare two fields."
When I had this problem I didn't find any plugins that can do this, but maybe someone else knows one.
Looked for a solution for this as well and came up with this filter creation.
I'm comparing the planned to the fixed (you can obviously do the same for affected instead).
Limitation is that you need to maintain the query for each release you are fixing to:
("Planned for Version" in ("2.3.0") AND fixVersion not in ("2.3.0")) OR
("Planned for Version" in ("2.4.0") AND fixVersion not in ("2.4.0"))
There are several questions on StackOverflow that seem to have answers that contradict each other on the subject of ADO/OleDB, delphi TADOQuery/TADOCommand and the subject of parameters.
Parameters can be introduced two ways, in the CommandText or SQL property of an ADO component. Named parameters, which work most of the time for me, are introduced with colons:
select a, b, c from bar where bat = :baz
This works, 99% of the time for me, just fine. Every now and then I find that ADO or Delphi's wrappers around it, won't accept ":baz" and requires that I write this instead:
select f, g, h from bar where bat = ?
This results in an unnamed parameter, instead of a named parameter. When an ADO Query or ADO Command contains only one parameter, this isn't a big deal. But that's not when ADO acts up on me. Yesterday it acted one way, and today, a different way with a dual-command in a single TADOCommand object, like this, with two commands in one CommandText string:
delete from bar where id = :id1
delete from bat where id = :id2
I had to change it to this:
delete from bar where id = ?
delete from bat where id = ?
It worked all day yesterday. Today, I had to change it back to the first version, to get it to work. The symptom was that the ADO parameters disappeared and would not come back, and when I try to execute the command I get an error, index out of range, when I try to access Parameters[0]. Nothing gives me any warning that the parameters are going away. It seems that a few connections to the ADO dataset, at designtime, jogs the TADOCommand component, in particular, and it "just breaks on me". It is particularly maddening when you're trying to write a query or a command, and you know it works, but the ADO component has decided not to accept "?" or ":x" right now. You can get around its total inability to function by switching from one to the other. But it frustrates me, and probably actually completely blocks other people. I know some people always dynamically build their SQL in code, and avoid using Parameters, and maybe this is why.
Possible answers to my question that I'm anticipating are:
ADO doesn't support multiple commands, or at least Delphi's wrappers don't. Or maybe TADOCommand just doesn't work reliably here.
Parameters are a buggy area in all of ADO, or all of Delphi's ADO wrappers?
You're doing it wrong.
I'm using Delphi XE2, but I've seen similarly dodgy behaviour in 2007, 2009, 2010, and XE.
I'm using Microsoft OLEDB Provider for SQL Server as my OLEDB Provider.
Named parameters with :? I always used it with #, even on Visual Studio (ADO.NET).
And in T-SQL parameters and variable are prefixed with #.
Do not remember having problems with that... Are you sure you doesn't choose Native Client
(installed with an SQL server client install) instead of OLEDB Provider for SQL Server (which
comes with Windows)?
Unfortunately, I've not used Delphi in awhile, so, and I don't have the means to validate this answer from the Delphi perspective.
This is the first time I've seen named parameters prefixed with a colon (:). Usually, in ADODB, the named parameters are prefixed with an at (#) and, yes, unnamed parameters are given with a question mark (?).
One significant advantage of named parameters is their ability to be reused, i.e.
INSERT INTO TABLE T VALUES (#id, #id, 'Hello World');
At the ADODB level. Once you used parameters, either named, or unnamed, you can use CommandText.Parameters.Refresh as a fast means of creating the parameters.
Yes there are some cases where parameters with ? fail. I have found sometimes I need to use :named parameters. Named parameters have an advantage for working with the DB Parameter values, since having the Name property set makes debugging the ADO query or dataset or table easier as well.
I do not understand why. If you have this problem, first check you are using the correct OLEDB provider, and check what version. Also check for potential parsing errors caused by bad SQL generated by you.
I suspect that an internal behaviour inside the OLEDB provider in code that I do not have source code for is to blame for this quirk. The Delphi ADO class wrappers are translators from Delphi's database component layer architecture to ADO's core query/table/dataset APIs all of which are under the hood wrappers around a set of COM objects that deal with ADO RecordSets.
I'm trying to follow the instructions for deploying a database via TFS build listed here:
http://www.mytechfinds.com/articles/software-testing/6-test-automation/64-db-deployment-tfs
The instructions include notes about how to configure a ConvertWorkspaceItem element. I've followed the directions, but TFS remains unhappy with my setting for 'Result' and 'Workspace'. For now, I simply entered the text from the directions ('dbproj' and 'Workspace', respectively). TFS complains about my values:
Compiler error(s) encountered processing expression "dbproj". 'dbproj' is not declared. It may be inaccessible due to its production level.
I'm trying to find basic tutorial information on the ConvertWorkspaceItem element, but other than the MSDN reference page there isn't a lot of info. Does anyone know much about configuring this element?
You need to specify valid variable names for both of these properties. there should already be a variable declared in the workflow called workspace, You will need to declare a variable of type string that you wish to receive the result of this activity and specify it's name as the Result property. It looks like in your linked article the author must have already created a variable called dbproj. At the bottom of the workflow designer is a variables tab where you can define your own variables.
i am getting following error,while accessing teamfoundation defect tracking application
"A field definition Symptom in the work item type definition file does not exist. Add a definition for this field or remove the reference to the field and try again."
can any body help?
Thanks
Suneetha.
The work items types definition must have been modified : the "Symptom" type has probably been renamed or deleted.
This can be done using the TFS Power Tools, if you are the admin on the TFS server.