I'm currently automating the process of importing XMI to Enterprise Architect using EA Script - JScript. I've been able to get definitions from existing packages GUID, Name, path to the package, create package.
The reference API from Sparx can be found here
Here's my current code
guid = "{3EC70CB6-28A1-40ed-ADD5-4B3AF5D89EED}"
Session.Output("GUID = " + guid);
Session.Output("GUID XML = " + project.GUIDtoXML(guid));
Session.Output("XMI file = " + svnPath + xmlPath);
result = project.ImportPackageXMI(project.GUIDtoXML(guid), svnPath + xmlPath, 1, 1);
Session.Output(result);
The following output shows that I got "Unknown package" while calling the API:
GUID = {3EC70CB6-28A1-40ed-ADD5-4B3AF5D89EED}
GUID XML = EAID_3EC70CB6_28A1_40ed_ADD5_4B3AF5D89EED
XMI file = D:\svn.xxx.com\yyy\docs\design\technical\class\Administration\SystemParameter.xml
Unknown package: EAID_3EC70CB6_28A1_40ed_ADD5_4B3AF5D89EED
I've googled for solution but google only shows about 17 results. The project Vienna in google code helps only a little.
So, does anyone know how to use ImportPackageXMI?
I can't tell from the information you've posted, but is it possible that you're trying to export a package from one project and import it into another?
Regardless of whether you tell EA to StripGUID, the package you import the XMI into must exist in the project, and that's what the PackageGUID specifies.
StripGUID 1 means a complete copy of the package contained in the XMI file is placed in the PackageGUID package. New GUIDs are created for all packages, elements, etc in the XMI file. In older versions of EA, this was the only way to make a deep copy of a package (Copy Package to Clipboard).
StripGUID 0 yields a few different results.
If the XMI package has the same GUID as PackageGUID, the current contents of the PackageGUID package are replaced by the XMI contents.
If the GUIDs are different:
If the XMI package GUID does not exist in the project, the XMI package is placed inside the PackageGUID package.
If the XMI package GUID exists, the import fails (conflicting packages).
In all four cases, the PackageGUID package must already exist.
Related
I am trying to import a UML Diagram (of a C++ project) I designed in a program called Visual Paradigm.
This program allows me to save the UML diagram in various formats
)
and when I choose the XMI format (supported by StarUML through an extension
) it allows me to pick the XMI version to save the file
The problem comes when I try to import the file in StarUml: when I try to load an XMI file (I tried every version) that cames from V.P. it says "Failed to load the file";
On the other hand, if I save the diagram into UML2 format and then I try to open it, StarUML just does nothing.
Do You have any suggestions to work this problem out?
Here is a zip archive with another simpler project containing source code and XMI files (different versions) generated by Visual Paradigm: Project.rar
In StarUML Github Issues there is something very similar to you issue.
I had the same problem and the workaround proposed worked for me, search for
file "xmi-reader.js", then change in function "loadFromFile" the line:
var XMINode = dom.getElementsByTagName('XMI')[0]
to
var XMINode = dom.getElementsByTagName('xmi:XMI')[0]
Adding the name space "xmi:" to the name of the element makes it work.
Depending on you version of StarUML the file name could be xmi21-reader.js .
This is related to a previous question but is more specifically about implementation.
To recap the previous question, I have a Pyinstaller app with 3rd party dependencies. As #AKX answered, the license text from those dependencies should be included in the Pyinstaller distribution.
Pyinstaller makes no attempt to handle this.
Therefore I am looking for a way to automate this process.
My project uses a virtual env, and the dependencies are located at:
\venv\Lib\site-packages
One option would be to recursivley search through this folder, and find any files that match a specific pattern (e.g LICENSE.txt). However, some of the packages do not ship with a license file, and instead just name the license in their metadata. For example, I am using openpyxl
there is a folder
\venv\Lib\site-packages\openpyxl-3.0.0-py3.7.egg-info
which contains a PKG-INFO file. This lists the license (MIT/Expat) but does specifically contain the license text. In this case would it be acceptable to include a copy of the PKG-INFO file, or some copy of the standard MIT license text?
Has anyone faced this issue and implemented a solution in an elegant way? #AKX (in the previous question linked to a tool which outputs the license information as text/json etc.. but doesn't actually attempt to move any files.
If anyone has a similar question, this is the solution I implemented, which seems to work pretty well for me:
At the top of my .spec file I added this
matches = ["LICENSE.txt","METADATA","PKG-INFO"]
lics = []
print("Find 3rd party dependency license files")
for root, dir, files in os.walk("venv\Lib\site-packages"):
for file in files:
if file in matches:
src = f"{root}/{file}"
dest = f"licenses/{os.path.basename(root)}"
lics.append((src,dest))
print(f"\tLicense file: {root}/{file}")
print(f"{len(lics)} dependency licenses found. Copying to /license folder in distribution")
which builds a list of tuples containing the source of the license or metadata, and the destination to copy it to in the distribution.
To do the actual copying, I made use of the datas keyword in the Analysis object, and simply expanded the list using *lics.
This could be adapted to include more matches or be smarter and parse the files, or something like that. It is also probably a bit wasteful and copies some files multiple times, but this seems like a minimal overhead for a tiny text file.
If anyone sees this and has suggestions or comments then I'd be happy to be further informed on this subject!
I have created an Eclipse CDT project that uses autotools from the libsndfile source code library. It builds fine in Eclipse. How do I modify this project to use it as a REDHAWK component the way that the dsp library and others are used?
Thanks!
There are multiple approaches to adding a shared library to work with REDHAWK. The simplest approach is to install the library on your GPP and follow the steps outlined in the section "Including External Libraries" found in the REDHAWK documentation.
The approach taken in the dsplib you asked about is slightly different. This creates a REDHAWK softpackage library dependency which is installed in the SDRROOT and deployed at runtime along with your component. Here are the steps to get a pre-exsisting c++ project working in REDHAWK. This answer does not cover getting the library to build or the process of importing it into eclipse as there are numerous posts on these topics:
Import the library into your IDE.
Build your shared library so that you have a shared object (.so file)
Add a .spd.xml file to your library such as the one found here.
Edit this .spd.xml file:
4a. Update the localfile tag to point to the location of your specific .so file.
4b. Ensure that the value of the implementation id tag is a unique revision number for your library
Add a .project file if it doesn't exist such as the one found found here. Open your .project file and ensure that the following natures are included:
<nature>gov.redhawk.ide.natures.sca.project</nature>
<nature>gov.redhawk.ide.natures.sca.component</nature>
You should now be able to drag your sofpackage library to the SDR root.
Here are the steps to update your individual components you are building to make use of your new library:
Edit the components Makefile.am in the cpp implementation folder. Edit the _CXXFLAGS to add the path to your header files, _LDADD to add your library, and _LDFLAGS to include the path to your library. See this example for how the agc component modifies these variables to include the dsp library.
Edit the .spd.xml file to include the softpackage dependency. Under the implementation section add a run time dependency on your library such as the one found here. Specifically - your dependency section should be as follows:
<dependency type="runtime_requirements">
<softpkgref>
<localfile name="XXXX"/>
<implref refid="YYYY"/>
</softpkgref>
</dependency>
XXXX is the path to your installed library .spd.xml file in the SDRROOT relative to the dom directory (it should start with /components) YYYY is your specific implementation value defined in 4b above.
I can't add comments, so I apologize for providing an "answer."
For me, Youssef's description worked perfectly for building components with shared libraries. However, in order to load the shared libraries at runtime, I needed to add the following to the makefile.am _LDFLAGS:
-Xlinker -rpath -Xlinker ../../dsp/Release
Where "/dsp/Release" is the relative path to whichever shared library you created.
I am using .Net 3.5/4.0 with code in C#.
I am trying to get a version number of an exe file on my C: drive.
For example path is: c:\Program\demo.exe. If the version number of demo.exe is 1.0.
How can i use this path to grab version number?.
You can use FileVersionInfo.FileVersion to fetch this from a path.
var versionInfo = FileVersionInfo.GetVersionInfo(pathToExe);
string version = versionInfo.FileVersion; // Will typically return "1.0.0.0" in your case
Updated and modernized 2018 (e.g. string interpolation of C#6):
The accepted answer is partly not correct (ProductVersion is not typically returning three-part version) and a bit misleading:
Here is a more complete answer. To get the main text not too lengthy I splitted it in a short(er) summary which may be "enough" for a lot of people. You are not obliged to read the detailed second part, so please no tl;dr :-)
Short summary:
There are different versions (assembly version, file version, product version) of each file, but normally you will have them all equal to not get "version hell" already on file level (it will come early enough).
The file version (which is visible in Explorer and used in setups/installations) is, what I would name the most important to bother.
To achieve this, simply comment out fileversion in AssemblyInfo.cs file as below. This assures that the three possible different versions of one file are the same!
[assembly: AssemblyVersion("1.1.2.")]
//[assembly: AssemblyFileVersion("1.1.2.")]
E.g. for Semantic versioning you want to get only 3 version parts out of possible 4 :
Having an automatic build counting for every Visual Studio build is useful. But this build counting is not always useful to tell your customers, internal or external. So for mentioning the file version to windows, in title dialogs, I would advice to show only three parts v1.2.3 (and of course with semantic versioning):
using System.Diagnostics;
...
var versInfo= FileVersionInfo.GetVersionInfo(pathToVersionedFile);
string fileVersionFull = versInfo.FileVersion; // No difference here for versinfo.ProductVersion if recommendation in AssemblyInfo.cs is followed
string fileVersionSemantic = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}";
string fileVersionFull2 = $"V{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}.{versInfo.FilePrivatePart}";
FileVersionFull2 is just showing how to handle all 4 parts, except the "V" it contains the same as FileVersionFull .
Details:
First is a cheat sheet about how to get and set the three versions:
File version: [assembly: AssemblyFileVersion(..)] => System.Diagnostics.FileVersionInfo.FileVersion
Product version: [assembly: AssemblyInformationalVersion(..)] => System.Diagnostics.FileVersionInfo.ProductVersion
Assembly version: [assembly: AssemblyVersion(..)] => System.Reflection.Assembly.Version
Especially the defaulting may be confusing. Recommended SO link to understand details: FileVersionInfo and AssemblyInfo
EntryAssembly vs. ExecutingAssembly
For fully considering every case for getting the version of the running app, search elsewhere for more details, e.g. here:
Which is better for getting assembly location , GetAssembly().Location or GetExecutingAssembly().Location
Especially, there can be confusion, if EntryAssembly or ExecutingAssembly should be used. They both have advantages and caveats.
If you have the following code not in the same assembly as the .exe, e.g. in a helper assembly, things get more complicated. Usually you would use EntryAssembly then, to get the version of the .exe.
But: For unit tests in Visual Studio to test routines in a parallel .exe project, GetEntryAssembly() doesn´t work (my env: NUnit, VS2017). But GetExecutingAssembly() doesn´t crash at least, only during unit test you get the assembly version of the test project. Fine enough for me.There may be situations which are not as simple.
If wanted, you can omit the declaration as static making it really possible to get versions of several different assemblies in one program.
public static class AppInfo
{
public static string FullAssemblyName { get; }
..
static AppInfo()
{
Assembly thisAssembly = null;
try
{
thisAssembly = Assembly.GetEntryAssembly();
}
finally
{
if (thisAssembly is null)
thisAssembly = Assembly.GetExecutingAssembly();
}
FullAssemblyName = thisAssembly.Location;
var versInfo = FileVersionInfo.GetVersionInfo(FullAssemblyName);
..
}
}
Product version vs. file version:
ProductVersion of a file is shown in Windows Explorer too. I would recommend to maximally differentiate ProductVersion and FileVersion in the most "customer-visible" file (mostly the main .exe of application). But it could be of course a choice to differentiate for every file of the "main" app and let them all have them all the "marketing" ProductVersion which is seen by customer.
But experience shows that it is neither necessary nor cheap to try to synchronize technical versions and marketing versions too much. Confusion doesn´t decrease really, costs increase. So the solution described in the first part here should do it mostly.
History: Assembly version vs. file version:
One reason for having different versions is also that one .NET assembly can originally consist of several files (modules)- theoretically. This is not used by Visual Studio and very seldom used elsewhere. This maybe one historical reason of giving the possibility to differentiate these two versions.
Technically the assembly version is relevant for .NET related versioning as GAC and Side-by-side versions, the file version is more relevant for classic setups, e.g. overwriting during updates or for shared files.
In the accepted answer a reference is made to "pathToExe".
This path can be retrieved and used as follows:
var assembly = Assembly.GetExecutingAssembly();
var fvi = FileVersionInfo.GetVersionInfo(assembly.Location);
var version = fvi.FileVersion; // or fvi.ProductVersion
Hope this saves someone from doing some unnecessary extra steps.
Where Program is your class name:
Console.WriteLine("Version = " + typeof(Program).Assembly.GetName().Version.ToString()) ;
I'm not sure if this is what you are looking for, but:
http://www.daniweb.com/software-development/csharp/threads/276174/c-code-to-get-dll-version
It says,
// Get the file version info for the notepad.
FileVersionInfo myFileVersionInfo = FileVersionInfo.GetVersionInfo(Environment.SystemDirectory + "\\notepad.exe");
// Print the file name and version number.
Console.WriteLine("File: " + myFileVersionInfo.FileDescription + '\n' + "Version number: " + myFileVersionInfo.FileVersion);
Use this, it works:
using System.Reflection;
string v = AssemblyName.GetAssemblyName("Path/filename.exe").Version.ToString();
This works good and returns the version provided in AssemblyVersion:
using System.Reflection;
infoFileVersionInfo versInfo = FileVersionInfo.GetVersionInfo("path.exe");
string version = $"v{versInfo.FileMajorPart}.{versInfo.FileMinorPart}.{versInfo.FileBuildPart}";
Solution 1
Dim fileVer As FileVersionInfo = FileVersionInfo.GetVersionInfo(Environment.CurrentDirectory + "\yourExe.exe")
yourLabel.Text = fileVer.FileVersion
Solution 2
Get File Version Number
yourLabel.Text = Application.ProductVersion
Both solutions will give 1.0.0.0
using the JavaCard Converter tool, I kept getting errors like
error: export file rmi.exp of package java.rmi not found.
and
error: export file framework.exp of package javacard.framework not found.
The errors disappeared gradually after I copied the directories beneath
/usr/local/javacard/java_card_kit-2_2_2/api_export_files
to the local directory. Now, that's clearly a hack. No, calling this a 'hack' would be an insult to just about any other real hack. This is clearly not how things are supposed to work, right?
So, how do I tell the converter tool where it should be looking for the .exp-files?
And, yes, I've set JC_HOME=/usr/local/javacard/java_card_kit-2_2_2, too.
Quote from Java Card 2.1 Development Kit User’s Guide - November 15, 1999 document:
"
You can use the -exportpath command option to specify the locations of export
files. The path consists of a list of root directories in which the Converter looks for
export files. Export files must be named as the last portion of the package name
followed by the extension .exp. Export files are located in a subdirectory called
javacard, following the Java Card directory naming convention.
For example, to load the export file of the package java.lang, if you have specified
-exportpath as c:\myexportfiles, the Converter searches the directory
c:\myexportfiles\java\lang\javacard for the export file lang.exp.
"
I suppose it should apply for 2.2.2 too.
So use appropriate -exportpath option for converter to point to your exp files and be sure the javacard subdir is created under the package dir for holding exp files.