I developed two eclipse plug-ins: a server and a client.
Either can be run separately in their own application, or they run in the same application as "embedded" mode.
For each operation mode, I created an eclipse product. The embedded product is basically the same as the client, but it also contains the server plugin which is then automatically activated.
Now, when it comes to setting up integration tests, I run into a problem: the product for the client and the embedded application use the same application id. Is there any way to distinguish between the two? Basically, I want to integration-test exactly what I defined in my embedded.product (of course with additional junit testing plugins). Is this possible in any way?
Related
I have a web job I've created and I want to deploy to azure. However I'm confused about the configuration when you create it.
It's a web job that's triggered from an azure storage queue. It works fine locally.
However when I go to create the web job in azure, I'm confused by the choices...my choices are Triggered or Continuous.
If I choose Continuous, I get a choice single or Multi.
If I choose Triggered, I'm given a choice of Scheduled or Manual. I don't want a Scheduled, and I'm not sure what Manual means...that doesn't seem like it's right either.
I know the web job that's triggered from the azure queue is really "polling" and not triggered...so it seems like continuous is the right choice. But I'm not sure.
So the question is...when creating a Web Job that's triggered from an Azure Queue, what is the right deploy configuration?
I sounds like you are using the Azure WebJobs SDK. In SDK scenarios, even though your individual functions are 'triggered', the WebJob as a while runs continuously (i.e. your exe keeps running and does its own internal triggering). So what you want is Continuous Multi. No reason to use singleton in most cases, and it's not relevant anyway until you scale out to multiple instances.
I was able to split the database and used packaging solution to distribute the front-end. I tested it the exe file and it worked fine. Now I am updating the forms and I cannot figure out a way of updating just the front-end (backend is on the server) wihtout going through the new installation of the new package. I did create the template file while going through the process of packaging the database.
I found this website but was afraid the unzip the file. Have any of you use this tool?
http://www.btabdevelopment.com/ts/freetools
Thank you
Some existing tools
Here is a list of deployment tools for Access front ends:
Auto FE Updater from Tony Toews (probably the best, but commercial)
Application Starter from Peter's Software
Front End Updater Utility, from Roger's Access Library
AutoUpdater, from the UtterAccess archives
The one you listed could also help.
More information on deployment
The issue is that there is no single way to update an Access application.
As you discovered, the packaging tools are nice, but they don't really take care of the most important, and complex, part of deploying software: how do you update an existing installation?
Access doesn't have a good story here, so there are many custom solutions, each with its flaws and advantages.
You were right that in any case, you must separate the backend database, containing only the tables, from the front-end, containing the code, forms and reports.
The front-end must be deployed to each user: the rule being that a front-end is meant to be used by a single user only.
What's in a good updater
So, what are the characteristics that you want in a good update story:
User should not have to do anything: you want the user to get the new version of the front-end as soon as it is made available, automatically.
This could mean that your front-end could check if there is a new version available on a remote folder before it allows the user to login or star any work.
If a version is available, it is then fetched and deployed.
Sometimes, because your development environment may be different from the user's environment (different server names, different shared folders, etc), you may also need to re-link the tables in the front-end to the correct path of the back-end after deployment.
What I am using for my deployments
For a few years now, I have perfected my own system that works without a stitch.
Instead of launching the application directly, when the user click the application icon, a small launcher application is started.
The launcher I use is a simple Click-Once application (so it can auto-update) written in .Net.
The launcher is responsible for ensuring that the main application is only running once, and also for checking and deploying new versions (or downgrading them) when updates are made available.
Updates are simply packaged into zip files that contain all the files necessary for a new update.
The name of the file contains the version number, like myAppFE-2013-08-01.zip so that sorting the list of clients packages by name would make it easy to pick the most up-to-date package.
All these front-end packages are stored on a shared folder on a server, for instance if my backend database is in \\myServer\myApp\DB, the front-end packages could be kept in \\myServer\myApp\FE.
When the launcher detects that a new package is available, it deletes the existing folder of the front-end on the user's machine and unzip the new package there instead.
Once the launcher has finished its tasks, it just launches the application frontend.
When the application front-end is started for the first time, it can do more checks to re-link tables if they point to the wrong location.
Notes
An alternative for detecting a new package would be to keep a small text file on the server that would contain the filename of the most current package.
Whenever a frontend is started it could check if the package name it is running is the same as the package name listed in the file. If not, then an upgrade/downgrade is necessary.
One of the advantages of this solution is that once the Access Runtime is installed, users can run in normal user session on the machine, without ever requiring administrator rights: the click-once launcher doesn't require any admin rights and if you deploy your access front-end under the user's %APPDATA% folder, you do not need elevated rights to update your front-end at all.
The first time you deploy, your launcher should also be responsible for registering the location of front-end folder as a Trusted Location so that Access allows it to run without VBA/Macros being disabled.
These are just a set of registry keys you can easily add under HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Access\Security\Trusted Locations\ (the exact registry key depends on your version of Office and whether you are on a 32 bit or 64 bit system).
I have a client who wants a control panel for the app I am developing them. The control panel is a Mac OSX application that allows the user to submit files (excel docs and such) to my MySQL database. Those files are then checked by the iOS app I have created for them.
I have no idea how to do this. I have the MySQL database all set up, and I have looked everywhere for a solution. Any help is appreciated.
I wouldn't try to connect to your MySQL database directly from your cell phone. It's a bad design for several reasons. Instead build a API on the same server as the MySQL database. It doesn't matter if you do it in java, php, c# or anything else. You might even find some product or open source project that can do this automatically. I've listed some benefits of doing it this way
It makes testing easier. You can write a test framework against your API that doesn't rely on or is using a phone.
It makes development faster. You don't need to emulate or use a phone to develop and test your table design and queries.
It gives you compatibility. When you need to change your database (and you do) you can create new APIs that the new version of the app uses while and old version still out there can continue to use the old API (that you might have to modify to still provide the same functionallity)
It gives you flexibility. If your user base grows and you might need to have replication for reads or sharded databases you build that into the API instead of into the app which is just a better way to do it.
One option would be to use PHP to handle all the database interaction.
Host the scripts on the server and just have the apps call them and get the scripts to return some sort of parseable response (I'd go for JSON).
I have never found a suitable Object-C based connector for MySQL. At this point I would suggest using a C/C++ connector. There's lots of examples of how to configure the connector for both C and C++. The hard part will be all of the data passed from the MySQL code and the Object-C code will that it will have to be in C types.
EDIT: An Example
I am working with Hudson here and I am trying to create a single job that users with different access can run. Based on their access level, they would see different options.
For instance:
A Developer when running this job would see the build stage and be able to see the build process, and deploy it to a development server.
The Release Engineer would see the same options as the developer, but also see that he can deploy the code to a different set of servers as well.
And so forth.
Is this even possible, like role based jobs. I know I can limit the access and who can do what, but this is a little different.
We have a product developed in C#.Net. It is not a web application but a desktop version. It connects to various databases like MSSQL, MySQL etc.
We keep on upgrading the versions of the software for bug fixes as well as new functionality.
These updates changes the exe as well as dll used and the database also.
We would like to know what are the different methods using which we can provide updates to our customer.
Consider deploying your app with ClickOnce . Lets your users easily install the application from a web server, and it has automatic support for updates. It's integrated with visual studio, and will generate the stuff you need with the push of a button.
Well, there are several different paths to take.
Simple: Just provide a new installer that overwrites the previous installation. Send the clients an email when it's ready or simply put it up on your site.
Mid level: Provide a "check for new version" function in your app that compares it's version number to one retrieved from a web service on your side. Fire up a browser to download it and run the installer if necessary...
Best (IMHO):
Create a wrapper application for yours. This wrapper is what would actually be started when they click your icon. It would check for new versions (again once every couple of weeks), then fire off the main program if everything is good. If an update exists give the user the option to download it. Download the file and replace the real app. Then launch it. BTW, This is pretty close to the Firefox model.