We are using Enterprise Architect for our models.
EA can be integrated with version control system, for that, it is required to set configuration from EA to the directory in SVN folder- in which the XMI files of packages will be stored.
The configuration settings process is a long and annoying process which we would like to be done automatically.
Is there a way to do this programmatically?
UPDATE: This is the window which requires the manual configuration for each machine.
Yes, there is. The API does not support selecting version control provider etc, but it does support adding/removing packages to/from version control and checking them in and out once the provider is set.
The methods are in the Package class (in the help file under Automation and Scripting -- Enterprise Architect Object Model -- Reference -- Repository Package -- Package Class):
VersionControlAdd()
VersionControlCheckin()
VersionControlCheckinEx()
VersionControlCheckout()
VersionControlGetLatest()
VersionControlGetStatus()
VersionControlPutLatest()
VersionControlRemove()
VersionControlResynchPkgStatus()
Repository.VersionControlResynchPkgStatuses() resynchronizes all version-controlled packages, but that's the only project-level version control method in the API.
You don't have to write an Add-In if it's a one-off thing. A stand-alone application has access to the Object Model API, whereas an Add-In (which is integrated into EA) also has access to the Add-In Model API (see Automation and Scripting -- Enterprise Architect Add-In Model).
The Add-In Model API fires a number of events when model elements are created, updated, etc, but no events are triggered by version control changes. So if you only need to add a number of packages to the version control repository, a stand-alone application can do that.
Have you referred to the best practices prescribed by Sparx? http://www.sparxsystems.com/WhitePapers/Version_Control.pdf
Whilst I agree it could be a time-consuming process to setup version control for the first time, there are several tricks which could make it less cumbersome.
E.g. COnfiguring the packages (or branches) in one model and then sharing the same to the rest of the team, and just letting them specify the Working Copy of the rewpository.
PS - It is also best not to interfere with the package structure in your SVN folder, and let EA take care of the same
Related
I am creating a simple C# desktop application that is pulling messages from Google Cloud PubSub. I noticed that PubSub is using Grpc.Core package that when installed is more than 500 mb! It contains many files that I don't need(for mac, android, etc.) and it doesn't seem reasonable to use such package if my application size is only few mb. There is a discussion here:
Why is Grpc.Core NuGet package so big?
In comments section it is said that it is possible to target more specific packages to suit specific needs. So my question is - is there more specific package/s that can be used to simply pull messages from Cloud PubSub to desktop application?
I feel your pain. (In fact, I feel it many times over. When I do a complete build of the google-cloud-dotnet repo that I work on, it pulls in those libraries many times over, and ends up being vast.)
It would be nice if you could add a sort of "negative dependency" to say "I don't want Grpc.Core even though Google.Cloud.PubSub.V1 depends on it indirectly, please use Grpc.Net.Client instead", but I don't believe there's any simple way of doing that in MSBuild projects.
We do make a "best-effort" attempt to support Grpc.Net.Client via the Google.Api.Gax.Grpc.GrpcNetClient package - you can depend on that package and then set the GrpcAdapter property in a ClientBuilderBase<TClient> to GrpcNetClientAdapter.Default. However:
The Pub/Sub libraries are slightly trickier to reconfigure than others, due to the manual layer of code wrapping the generated code. (I can look into how to perform that configuration if you're interested.)
We haven't done significant testing with Grpc.Net.Client, and the Pub/Sub library in particular performs a lot of streaming; while it should all just work, it's possible that there could be problems.
Doing that doesn't actually remove the Grpc.Core dependency anyway - so you'd need to manually remove the files you don't need.
There really isn't a more specific package that you can target - all I can suggest is that you delete the files you don't need. You could do that in a build target that runs post compile, for example. It's possible that there's some cunning way to tell MSBuild that when it would copy (say) the iOS libraries into a specific location, just exclude them instead - but I don't know enough MSBuild to say how you'd do that (when they're being copied due to a dependency rather than due to the project itself).
I am using Visual Studio 2008
I have two applications (AppA and AppB) that I what to be installed using one msi-installer.
Both applications have reference AppC.
This is what I did:
I created Setup Project
I created two subfolders inside of Application Folder (AppA and AppB)
I added Project Output for AppA into related subfolder
I added Project Output for AppB into related subfolder
Problem: AppC did not appear in subfolder for AppB. It looks like dependency can only appear once.
Could please tell me how to resolve this?
You should be adding "Primary Output from AppC" specifically to each of the application folders. This version of VS Setup does not appear to detect that the same dependency needs to be included in two application folders.
There are a lot of recorded problems with the VS Setup and Deployment project, especially in regards to dependency detection. Also consider that MS has stopped shipping this project type, and has chosen the ISLE as its replacement (I would recommend using WIX instead - its free and is a more modern toolset when compared to Flexera's offerings).
A merge module is overkill for a single assembly. If you had a package of assemblies that need things like COM exposure or other group behavior things that you dont want to repeat (and possibly get wrong), then a merge module is more appropriate.
The GUI designer for MonoDevelop (Stetic) provides design-time support for widgets, such as the Notebook widget, which has options for Insert Page Before and Insert Page After. It also allows me to drop child widgets onto those separate pages.
Is this implemented directly in Gtk#? Where can I examine the code for this? How can I implement this for my own custom widgets? I want to create a notebook-like navigation control (similar to MS Outlook 2007/2010/2013) that can be designed using drag-and-drop with Stetic.
I have already tried searching through the source for MonoDevelop and Gtk#. It seems to me this may be implemented in a similar manner with additional classes and attributes like in Visual Studio with Attributes and Design-Time Support but I cannot find any evidence of that.
In MonoDevelop, Stetic is defined as a member in AddIns. Technically, it is always available/installed, so it is not something you deal with from the Add In Manager.
So you are looking for:
MonoDevelop.GtkCore.dll
libstetic.dll
libsteticui.dll
During a monodevelop build, assuming you have monodevelop code local, those get built and placed in:
monodevelop/main/build/AddIns/MonoDevelop.GtkCore
The source code that you are looking for is at:
monodevelop/main/src/addins/*
I would highly recommend in order to jump-start you:
git clone the monodevelop source repo
cd into the repo
./configure --help (to figure out what options you need to use)
Once you can build monodevelop, you can use that build version or (Xamarin
Starter+) to open workspace MonoDevelop.mdw (in root dir of repo)
Navigate to:
Main / Addins / MonoDevelop.GtkCore / libstetic
Main / Addins / MonoDevelop.GtkCore / libsteticui
Have fun storming the castle ;-)
The Stetic designer in MonoDevelop simply does not support the concept of "pluggable" widget design or commands. It's just written the way it is for the controls it supports and anything else has to be added via the Custom Widget widget and manipulated via code.
In the System.AddIn (aka MAF) pipeline adapters, there is a lot of manual copying of values from one DTO type to another - from HostView types to Pipeline Contract types and from Pipeline Contract types to AddIn view types (and back again). This seems like an ideal situation to use automapper.
However I am unsure as to the correct way to use and package 3rd party assemblies in the HostView and AddInView adapters, especially when AddIn activation is in a separate AppDomain.
I tried the following:
add nuget reference for automapper to AddIn adapter project and create the mapping profiles within. (I used a static ctor to the adapter that initializes the profiles cos MAF is responsible for instantiating the adapter.)
Counter-intuitively, to get the pipeline to locate and activate AddIns supported by the adapter, I had to ensure that the automapper DLL lived in the bin dir of my Host - having the automapper DLL in the "AddInAdapters" folder beside the actual adapter DLL had no effect.
With this arrangement, I was able to find and activate the AddIn on my dev box (win 7). But the exact same binaries would not work on Server2008R2. (I know, I know: I don't control the choice of development or server OS)
We are using (and targeting) .Net 4.5.1 - yep, it's on desktop and server. We are using automapper 2.2.1 - nope, it's not in the GAC of my dev box
Where should 3rd party assemblies used by Adapters be located (both AddIn side and Host side). Especially when considering AppDomain isolation
Why would the above arrangement work on Windows 7, but not 2008R2?
On the host side, it should live in the root output directory of your application. All of the host dlls are loaded in your app domain and the assembly resolver will look in the location of your running assembly for the automapper dll.
On the Addin side, it should live in the addin adapter directory. The addin adapter and addin view are loaded into the new app domain and require their own copy of this dll.
One thing to be careful with when using third party libraries anywhere in your pipeline is it can make versioning your pipeline painful. If you are loading multiple versions of your pipeline to allow for V1 and V2 addins to still work, if they depend on different versions of an assembly, you may run into problems in reconciling this. If you don't care about pipeline versioning, then this is less of a concern.
I'm working with Visual Studio 2010 and WinForms, .Net 4.0 (C#). I'm building an application with a lot of DLL (150). When I provide the application to my client, it's :
The Executable (.exe)
Dll files (.dll)
Each Dll is related to a module of the application, for example :
Ado.dll (provide access to database)
AccesManagement.dll (this module allows to manage users in the application)
Import.dll (this module allows the user to import data to the application)
etc.
When my client find a bug in the application, I correct it and I provide him impacted DLLs (in order to avoid him to test all the application). It can be for example the Import Dll.
The thing is, after some deliveries, we can have compatibility problems between Dll (a method that doesn't exist anymore in a new DLL for example). To avoid this problem, I would like to find a tool capable of checking compatibility between differents DLL.
I would like something like :
I specify the directory of the program to analyse (executable + Dll)
I launch the analyse
The program tells me for example : Error between Import.dll and Ado.dll, there is a class xxx in Import.dll expecting a method named xxx in the class xxx of Ado.dll
I've found some tools able to compare two versions of a Dll and provide added and removed members (Libcheck, ApiChange), but it's too complicated for me to do that because there are to many changes.
I think you may have a configuration management problem here -- at least as much as you've got a "compatibility" problem.
I'd recommend you find a way to track what versions of which assemblies each of your customers is using so that (1) you know what they're using when you decide what to ship, and (2) when they report bugs, you can replicate their setup (and thus, replicate their bug). If that sounds like a lot of work, it is. This is why a lot of software development shops take steps to ensure that there's a limit to the variation in setups among customers. It's nearly certain that you'll end up with some variation from customer-to-customer, but anything you can do to manage that problem will be beneficial.
Beyond the process implications, if you really need to create a "pluggable" environment, you probably need to create some interfaces for your objects to control the points where they connect, and you should probably look at Microsoft's Managed Extensibility Framework (MEF). MEF can help you manage the way objects "demand" behaviors from other objects.
I finally found a solution to my problem.
Since I'm :
Using SourceSafe and adding labels with the version of the application I'm building
Tagging each of my DLL with the version of the application
I built a program which is capable of :
Opening each Dll of a folder to read the version of the application in it
Getting from SourceSafe each project for the version specified in the DLL (With the functionnality "Get Label")
Then I just have to build the projet. If there is any compilation error, there is a compatibility problem.
This solution can avoid big compatibility problems, but you can still have compatibility problems which can't be seen with a compilation...