ClearCase checking in and out using c# - c#

Basically I am working on a project where I can select an excel document within clearCase and run my ribbon program which updates the tables onto it. What I want to do in VisualStudio is make it so that the document, gets checked out when you run my addin, but then checks it back in once it is done running.
Is this possible?
Thanks for the help.

There is a very powerfull command tool for ClearCase named cleartool.
Here the full reference ClearTool Help
I would suggest you use Process.Start() to trigger check-in/check-out operations.
The syntax might be very simple like:
cleartool checkout "filename"
Another option would be to use ClearCase COM API. I am not sure they have a .NET library as well. Jus google for "ClearCase Automation Library (CAL)".
In fact those do the same job the same way. There are only twotop-level CAL objects that can be used to execute a cleartool sub-command. One of them is Clearcase.Cleartool object (which only has one method CMDEXE).

You can use the CAL interface (Rational ClearCase Automation Library) and call the appropriate command from a VB script (or a VB macro from Excel).
In this CAL script example, you can see several ways to do just that, including creating a cleartool object.
Set CL = CreateObject("ClearCase.ClearTool")
Here is another example, where a checkout is performed from a VB script:
Dim CC As object
Dim Ver As object
Dim CheckedOutFile As object
On Error Resume Next
Set CC = CreateObject("ClearCase.Application")
'Return message regarding ability to connect to Clearcase
If CC Is Nothing Then
MsgBox "NOTHING"
Exit Sub
Else
MsgBox "CONNECTED"
End If
'Find the Version of the ClearCase File
Set Ver = CC.Version("\\view\gustaf-pc_localView\ScriptTest\testModel.mdl")
MsgBox "version = " & Ver
'Checkout file
Set CheckedOutFile = Ver.CheckOut(ccReserved, "test checkout")
If Err.Number <> 0 Then
MsgBox "Checkout Error: " & Err.Description
Else
MsgBox "Checkout successful"
End If
The OP Berbies reports:
ClearCase.ClearTool checkingOut = new ClearCase.ClearTool();
string fileOut = #"fileName";
checkingOut.CmdExec(#"checkout """ + fileOut + #"""");
Then just changed the variables for when you check it back in.

Unfortunately, it doesn't work properly with the answer I stated before because what it ends up doing is adding another version to your branch instead of creating another version in the main branch, I fixed this issue with this:
void GetVersions(string sourcefile)
{
ClearCase.CCElement element = m_CC.get_Element(sourcefile);
if (element != null)
{
ClearCase.CCVersion latestVersion = null;
FileInfo fi = new FileInfo(sourcefile);
latestVersion = element.get_Version();
if (latestVersion != null)
{
ClearCase.CCBranch branch = latestVersion.Branch;
ClearCase.CCCheckedOutFile file = latestVersion.CheckOut(ClearCase.CCReservedState.ccReserved, "", false, ClearCase.CCVersionToCheckOut.ccVersion_SpecificVersion, true, false);
string path = file.ExtendedPath;
}
}
}
void checkIn(string sourcefile)
{
ClearCase.CCElement element = m_CC.get_Element(sourcefile);
element.CheckedOutFile.CheckIn("", true, sourcefile, ClearCase.CCKeepState.ccKeep);
}
This way you can check it back in using your own branch to create another version for the main document. This is really important when using source control.

Related

Installshield Automation Interface - Always Overwrite

I am trying to automate the creation of install packages for the company i work for and am using the Installshield Automation Interface to create an MSI project. One of the things we have done up to now (manually if you can believe it) is go through all of the files we want to release after importing them into installshield and setting them to "Always overwrite" on a folder by folder basis since it seems you cant do it recursively on a parent folder. When creating a Basic MSI on the installshield GUI it lets you do this, however when creating an MSI via the COM object it appears this option is only available to InstallScript which i cant make an MSI with.
Anywho my code kinda looks like this
static void AddFiles(string[] aFiles, ISWiAuto24.ISWiProject oISProj, string sProjName, string ePackName)
{
oISProj.OpenProject(sProjName, false);
string installdirectory = "[ProgramFilesFolder]" + ePackName;
oISProj.INSTALLDIR = installdirectory;
Console.WriteLine("Adding ePack files");
for (int i = 0; i < aFiles.Length;i++ )
{
Console.WriteLine(aFiles[i]);
ISWiComponent NewComponent = oISProj.AddComponent("Component_"+i);
string string_PathToFile = aFiles[i].Substring(0,aFiles[i].LastIndexOf("\\"));
string string_RelativeToInstallDir = string_PathToFile.Substring(aFiles[i].LastIndexOf(ePackName) + ePackName.Length);
NewComponent.Destination = installdirectory+string_RelativeToInstallDir ;
NewComponent.AddFile(aFiles[i]);
/*----------------------------Fails Here--------------------------------------*/
NewComponent.OverwriteMainOptions=0;
/*----------------------------------------------------------------------------*/
}
oISProj.SaveProject();
oISProj.CloseProject();
Console.WriteLine("Done");
}
static voidMain(string[] args){
ISWiAuto24.ISWiProject oISProj = new ISWiAuto24.ISWiProject();
string ePackName = "ThisMonthsBundle"
string[] aFiles = new[] {#"c:/Foo/Roo/Goo/"+ePackName+"/File0",#"c:/Foo/Roo/Goo/"+ePackName+"/File1",#"c:/Foo/Roo/Goo/"+ePackName+"/File2",#"c:/Foo/Roo/Goo/File3"}
string sProjName = "C:/Foo/Bar.ism"
oISProj.CreateProject(sProjName, ISWiProjectType.eptMsi);
AddFiles(aFiles,oISProj,sProjName);
}
does anyone know a way around this?
the error is: COM Exception was unhandled - This property is not supported for Basic MSI Project. You need to remove the line that calls the property from your automation code.
I found an old forum post back in 2010 on the flexera community forum where a flexera developer responded to a user saying that this can be done like so:
ISWiComponent NewComponent = oISProj.AddComponent("Component_1");
NewComponent.Destination = "[ProgramFilesFolder]" + "ProgramName";
NewComponent.AddFile("c:\File1");
ISWiFiles Files = NewComponent.ISWiFiles;
foreach (ISWiFile File in Files)
{
File.OverrideSystemVersion = true;
File.Version = "65535.0.0.0";
}
the developer in question recognised the need for the automation interface to support the ISWiFile.AlwaysOverwrite property and raised a work order for it. i guess they just havent gotten around to it in the 8 years since
https://community.flexerasoftware.com/showthread.php?194448-installshield-2009-automation-File-property-quot-Always-overwrite-quot
Anyway, The above appears to work

System.Runtime.InteropServices.COMException when I run this Interop code with word

When I run this code to take the text off a word document it ends with multiple System.Runtime.InteropServices.COMException 's
Private Sub Button4_Click(sender As Object, e As EventArgs) Handles Button4.Click
If Origcv = "" Then
Label10.Text = "Select a CV"
Else
' Create application instance.
Dim app As Application = New Application
' Open specified file.
Dim doc As Document = app.Documents.Open(Origcv)
' Loop through all words.
Dim count As Integer = doc.Words.Count
Dim cvw(count) As String
For i As Integer = 1 To count
' Write word to screen.
Dim text As String = doc.Words(i).Text
cvw(i) = doc.Words(i).Text
Next
' Quit the application.
app.Quit()
The errors all come on the doc.words(I).text even though the .count has succeeded. I have installed all components of word and .net and still can't get this to work. I used to have it working fine when I used the same code before on my laptop before it was factory reset so I assume I am missing some kind of component or setting, the interop.word reference is recognized and has the file path on the references tab. Any help here need to get this finished quickly and this is literally the first hurdle.
Any help appreciated
I believe your problem is Dim app As Application = New Application This kind of construct is always dangerous. Many namespaces use Application - you have no qualifier that tells .NET which application is meant. The fact that Documents.Open works could also be because the namespace .NET is referencing also has a Documents class.
If you fully qualify it:
Dim app As Microsoft.Office.Interop.Word.Application = New Microsoft.Office.Interop.Word.Application()
I believe the problem will go away.
If it does, put an Imports at the top of the module that assigns an Alias to the namespace then use the Alias to qualify objects in the Word namespace (makes things shorter):
Imports Word = Microsoft.Office.Interop.Word
Then
Dim app as Word.Application = New Word.Application()
Dim doc as Word.Document = app.Documents.Open(Origcv)

Can't run macro via interop if it's in a worksheet?

I'm using the following code to run a VBA macro via C# Excel interop:
public void macroTest()
{
Excel.Application xlApp = new Excel.Application();
xlApp.Visible = true;
string bkPath = #"C:\somePath\someBk.xlsm";
Excel.Workbook bk = xlApp.Workbooks.Open(bkPath);
string bkName = bk.Name;
string macroName = "testThisMacro_m";
string runString = "'" + bkName + "'!"+macroName;
xlApp.Run(runString);
bk.Close(false);
xlApp.Quit();
}
testThisMacro_m is in a module testMacro, and this runs successfully. When I replace it with:
string macroName = "testThisMacro_s";
where testThisMacro_s has its code in Sheet1, the xlApp.Run() line gives the following COM Exception:
Cannot run the macro ''someBk.xlsm'!testThisMacro_s'.
The macro may not be available in this workbook or all macros may be disabled.
I checked macro security settings, and they are indeed set to "Disable with notification", but being able to run a macro from a module and not from a worksheet seems to indicate that this is a different issue than application-level macro security.
Is there something different that I have to do when making an interop call to a macro in a worksheet?
UPDATE: I was able to get the macro to execute by changing the call to:
string macroName = "Sheet1.testThisMacro_s"
but it seems that this hands control back to C# before the macro completes, so now I need to figure out how to check for macro completion (probably a different question).
A Worksheet object is an object - and objects are defined with class modules. Worksheets, workbooks, user forms; they're all objects. And you can't just call a method on an object, if you don't have an instance of that object.
Macros work off standard modules, which aren't objects, and don't need to be instantiated.
Application.Run can't call methods of an object, that's why macros need to be in standard modules.
I was able to get the macro to execute by changing the call to:
string macroName = "Sheet1.testThisMacro_s"
Wouldn't a helper sub solve both of your problems, re: Mat's Mug's reply concerning instantiation?
In some standard module:
Sub testHelperSubToBeCalledFromInterop
Call Sheet1.testThisMacro_s
End Sub
EDIT:

c# Visual Studio ...adding references programmatically

Is there anyway that a reference can be added to a solution programmatically?
I have an add-in button, when the user presses it, I want a reference to be added.
The reason is, I have created a piece of software that I want to be integrated into any given VS program (if the developer wants it), they would simply click the add-in button and the reference would be loaded in the current solution.
Is this possible?
Something like this I haven't tested it
get the environment
EnvDTE80.DTE2 pEnv = null;
Type myType = Type.GetTypeFromProgID("VisualStudio.DTE.8.0");
pEnv = (EnvDTE80.DTE2)Activator.CreateInstance(myType, true);
get the solution.
Solution2 pSolution = (Solution2)pEnv.VS.Solution;
get the project that you want
Project pProject = pSolution.Projects[0];
add the reference
pProject.References.Add(string referenceFilePath);
There is an example on CodeProject.
The functionality is contained within a single class elRefManager and the method to call is CheckReferences. The code can be looked at here by selecting the elRefManager.cs file on the left hand side.
As seen in the article you could do...
private void button1_Click(object sender, System.EventArgs e)
{
int ec;
ec=elRefManager.CheckReferences(null, new string[] {textBox1.Text});
if (ec<0)
MessageBox.Show("An error occurred adding this reference");
if (ec>0)
MessageBox.Show("Could not add " + textBox1.Text +
"\nCheck its spelling and try again");
}
System.Assembly.load Allows you to call functions in a library that were not built with your program.
If you want to add a reference to the project so that its in the solution you can use the following. Basically the same as #Scots answer.
I did it in a macro which is vb but I'm sure you can get the idea
DTE.Windows.Item(Constants.vsWindowKindSolutionExplorer).Activate()
Dim objProject As EnvDTE.Project
Dim i As Long
i = DTE.Solution.Projects.Count
For Each objProject In DTE.Solution.Projects
If (objProject.Name() = "csCA") Then
Dim vsproj As VSLangProj.VSProject
vsproj = objProject.Object
vsproj.References.Add("C:\Users\test.dll")
End If
Next

Can I use a language other than VBScript to programmatically execute QTP Tests?

I have VBScript code which launches QuickTest Professional, executes a series of QTP tests, and emails the results. This works well, but I would prefer to use a language with better tools support (a good IDE for example). I am currently calling .Net libraries from the launch script, so I was wondering if it was possible to use a language like C# to accomplish the same task. If so, are there any good resources which address this? I could find very little on this topic via Google and there do not seem to be any other questions on SO about this topic.
For clarity, I have included the code for the routine that does the bulk of the work. This does not include the .Net declarations, but failedTestsList and allTestsList are instances of System.ArrayList.
EDIT: All the QTP documentation examples use VBScript, but as you can see, the code is just creating the QTP objects. I would assume these would be callable from another language which supported creation of these objects. It just seems from my Google failures that no one is doing it.
Sub ExecuteQTPTest(name)
Dim App, resultsPath
Dim testPath, testResults
testPath = name
allTestsList.Add(name)
Set App = CreateObject("QuickTest.Application")
App.Launch
App.Visible = False
App.Open testPath
SetQTPTestOptions(App)
SetQTPRunOptions(App)
SetQTPWebOptions(App)
App.Folders.RemoveAll
Dim qtpTest, qtpResultsOpt
Set qtpTest = App.Test
Set qtpResultsOpt = CreateObject("QuickTest.RunResultsOptions")
resultsPath = testPath & "\RES1"
qtpResultsOpt.ResultsLocation = resultsPath
qtpTest.Run qtpResultsOpt ''// Run the test
testResults = "Test Status: " & qtpTest.LastRunResults.Status & vbCrLf & _
"Last Error: " & qtpTest.LastRunResults.LastError & vbCrLf & _
"Detailed Results located at " & qtpTest.LastRunResults.Path & _
" can be viewed with the QTP Results Viewer Tool " & vbCrLf
If qtpTest.LastRunResults.Status <> "Passed" Then
g_testRunPassed = False
failureCount = failureCount + 1
failedTestsList.Add(name)
LogResults testResults, name
End If
qtpTest.Close
Set qtpResultsOpt = Nothing
Set qtpTest = Nothing
App.Quit
Set App = Nothing
End Sub
Apologies, but I don't have time to convert your full sample over to C#. I've thrown together a simple demo that should get you going. This just uses C# to open a QTP instance:
using System;
using QTObjectModelLib;
namespace QtpDemo
{
class QtpDriver
{
[STAThread]
static void Main(string[] args)
{
Application app = new Application();
app.Launch();
app.Visible = true;
}
}
}
You'll need to compile it linking to C:\Program Files\Mercury Interactive\QuickTest Professional\bin\QTObjectModelLib.dll (which is the .NET interop library for QTObjectModel.dll) and have that and QTObjectModel.dll in your app directory when you run it.
It shouldn't be that hard from here for you to convert any object declarations and function calls from VBScript to C#. Please ask if anything's unclear.
To your other point about samples on the internet - there are plenty of people out there doing more advanced stuff with QTP and QC, but I think any really clever solutions aren't shared. I, for example, would probably be prohibited from sharing such things by my employment contract, but I agree with you - there is a dearth of good QTP API samples out there, at least on Google. Having said that, I heartily recommend the SQA Forums for your QTP and QC needs.
Rich
YES, you can use anything that can "do" COM, and that includes C#.
Also VB.NET of course.
and Perl, Python, Javascript, and others.
With no help from google, you will have to follow your nose, on how to deal with the interface, but it's not that difficult when you have the existing example. Also your vendor, ideally, will have documented the COM interface for you.
if this still matters to you... QTP 11 allows you to script in C#
Please see the following answer as it will give you the exact information you are looking for to connect a C# application with QTP/UFT:
https://stackoverflow.com/a/19887866/2794121

Categories