I working on a Google Sheet Add-on. When testing the addon [from the legacy editor Run --> Test as add-on] and selecting "Test with latest code" sometime it does not run the latest code (I know this because I've made changes to the code and error messages are pointing old line numbers).
Saving a version number and specifying that in the test screen doesn't seem to help either.
Turns out the problems was that parts of my "Test" Add-on was running from my production deploy add-on NOT my test code. This was super confusing and took a long time to understand.
I knew that "Installable Triggers" (aka onOpen) cannot be installed or tested via editor (you will get error message when trying to install them) but thought "Simple Triggers" did work since the onInstall work and runs when testing an Add-on. However this is not true, other simpleTriggers - such as onEdit - will not run in test mode.
My test spreadsheet had magically enabled the deployed Add On [you should have to manually enabled addon to be available for each spreadsheet] so onEdit event were running creating log messages right next to development code messages - super confusing!
To avoid this problem, I completely uninstall the Production Addon from my account. Not ideal since I'll have to re-install it to test production deploys.
Also I had to rewrite my trigger code so it could be tested manually via menu bar (since the "even object" isn't available) otherwise you must deploy your code every time you want to add a debug statement.
I hope this save someone some head banging!
Related
I Just installed Ranorex studio trial version 8.3.0. While I was going through tutorial trying to learn it, I encountered a problem. After creating new solution when I try to record test, it's just start recording. It doesn't give option to select run an application or open a browser to provide specific path or URL.
I have tried a lot but it's the same way. As I have seen in many tutorials when you click on record it asks you to choose one of these. Is something changed in new release?
Yes, it is part of the new release of Ranorex 8.3.0. Ranorex has made some changes to Ranorex Recorder and now it no longer asks to select the application you want to test. I think the workaround would be that you can leave your application open before recording and also add the application to the white-list so that when it runs the test it can only focus on the white-listed application and hence would increase efficiency.
More information can be found here https://www.ranorex.com/what-is-new/ under "Ranorex Recorder Improvements" or in the "Release Notes" https://www.ranorex.com/release-notes/
We have e2e test integrated with Jenkins system. For a few weeks this test successfully ran both, locally and from Jenkins (as a part of the build pipeline).
At the end of Sprint, I modified the script to reflect Sprint changes and made sure it passed locally. Then, I merged the changes with master. Now, e2e runs from Jenkins are failing 100% of the time, while when I locally connect to QA envs there is no problem.
The error I am getting is - Element is not clickable at point (x, y) which I cannot reproduce locally.
The server doesn't have a real screen so I cannot go out there and see what's going on. Resolutions are perfectly matching. I have other people running this test locally and there is no problem.
What could possibly cause these failures and how do I troubleshoot this problem?
Thanks for your help!
Its a question from 1000ft and pretty difficult to identify where exactly the issue could be but I listed down some probable causes/debugging tips that could help you
1.Whats your checkout strategy from source code repository? Check job workspace and it should have the most recent code and check if its indeed the latest one.
May be configure Job to always pick a new version instead of 'update'
2.Add a reporter based on the test framework you are using especially the ones which provide screenshots. Refer my blog for more details -
3.Check the stack trace of your error from Jenkins console report and verify the exact trigerring point
I need suggestions on how to update my application. The form application is going to be put on a drive for many users to be using non stop all day. What are ways to update the program or allow updates to the program while it being use? If I update the program and recreate a new build for it, trying to copy paste over the old application will not let me if someone else has it open. Open to any suggestions.
Option 1: Deploy the app with ClickOnce and set it to check for updates every time it runs.
ClickOnce:
In your project settings, click on the Publish tab.
From here you can configure where the app publishes to and if it should be installed or available online only.
Once you have it all configured you will use the Publish Now button to compile and upload your update to the publish location. Each time your users open the app it will check for updates at your set location. To have your app check for updates programmatically use code like the one found at this MSDN link - https://msdn.microsoft.com/en-us/library/ms404263.aspx
You should note that users will no longer run an exe directly and you won't copy your exe to the publish folder. Your users will have to click on a file that has the extension of .application. The users could create a shortcut to this .application file to place on their desktop or wherever they want.
Also note that if using ClickOnce and you publish a bad version (with a bug for instance) then your users have the ability to revert back to the previous version so that they can continue using the app while you fix the bug. Your users also have the option to skip an update so you'll want to inform them to never skip the updates.
Option 2: Create an app that publishes your main app
I'll admit that this answer is not a great way
You could create another exe for the purpose of publishing the main exe. The publishing exe will simply try to copy the new exe over the old one and keep trying until it is successful. It will be successful when all instances of the program are terminated.
Option 3: Use a database
Have your app check a database value that indicates an update is available. Prompt users using the app to shutdown and don't allow other instances to startup while the database value is set to update available.
You could use nUpdate, a free and open-source .NET-library for updating applications that also cares about the safety of your update packages which is an important fact. Many update routines do not validate the packages they downloaded, which can result in serious damage, if updates are replaced by malware (as it happened to the puush-service some time ago).
nUpdate is especially designed for Windows Forms-applications.
It is still being improved at the moment and the support for WPF-applications will be added soon, but the current version is very stable, yet.
I'm attempting to automate the build of a source controlled MS Access application (it's only the front-end, the back-end is SQL Server). The Access client is published to the users via a simple C# console app via ClickOnce... It's in that console project that I'm also building the MS Access application via a custom msbuild tasks from this CodePlex library: https://buildmsaccessdb.codeplex.com/ (which is also mentinoed in another StackOverflow post on the subject). On my machine, it all works fine. The Access source code is compiled into an ACCDB, which is then converted into an ACCDE which is what gets included in the published app.
However, when I make it an automated build in TFS, it always stalls at the step where it converts the ACCDB to an ACCDE. I've tried a variety of ways for executing the "Make ACCDE" (SysCmd 603) command. I've tried it in powershell scripts, in VBA, etc... but it always seems to stall. Is that because the automated build process is not an interactive process and maybe the the SysCmd 603 needs to be ran interactively? If I stop the build and take a look at the ACCDB, everything is good. It compiles and can be manually compiled into an ACCDE... so it's not that the ACCDB isn't compilable.
I'd like to test it as an interactive TFS service but I don't control the service account it's running under.
Any tips on suggestions are welcome and thanks in advance! We have this whole automated build and release process up and nearly working except for this one piece!
I don't know much about the MSBuild task library, but from a quick look at the source it looks like it opens Access to run the tasks and interacts with a dialog box at one point. If that's the case you'll definitely need to run the build in interactive mode.
The fact that your build is hanging and not erroring out would also indicate this is the case.
Even though you don't control the service account, I would presume there's someone else in your organisation that does. I'd suggest you work with them and to try the build in interactive mode and ensure it works. If needed you could always set up a second build machine that runs in interactive mode, with the current build server remaining in "run as a service" mode.
Just getting ready to upgrade from 5.1 to 6.3. We have never performed an upgrade before.
About the upgrade path: When installing the updates, do I need to install the hotfixes, or just the major releases? (My gut says only major releases).
I found the documentation here:
http://www.sitefinity.com/documentation/documentationarticles/upgrading-you-sitefinity-5.1-project-to-the-latest-version
Is this documentation enough to make a smooth upgrade?
Yeah, just follow the documentation in the link you posted.
My process is to take full backups of the site files and database then perform the upgrade locally. Do the first step in the upgrade path then run through the site to test, back end and front end, then run the next step in the upgrade, and so on. I suppose if you want to be extra careful you could take additional backups between each upgrade step but that's probably overkill.
When making the web.config changes, there is an option to have Project Manager merge them for you but I end up just using Beyond Compare to compare the _EmptyProject folder in the extracted Project Manger files to my local files and do the web.config changes through a file compare. It cuts down on the differences in files from upgrade to upgrade and shows you whats been changed. The _EmptyProject folder is essentially the vanilla Sitefinty site files for that version.
Once the site is fully upgraded locally, I just publish the site in Visual Studio, copy the files over to the live site and overwrite the live database with a backup of my locally upgraded database.
Hope that helps.
I have upgraded Sitefinity 5.1 to 6.0, on a website which is in production (which included going through a couple of steps for the versions between).
I just followed the guidelines, and it went fine.
Now there are a couple of things you need to be aware of :
Source control
If your Sitefinity solution is on "Source Control", you should create a new duplicate of your solution, and disconnect this one(newly created) from "Source Control" before starting the upgrade. And of course you do the upgrade on the solution which is not in Source Control. Because you will probably have a lot of dll's to integrate, and if you have the project manager, your sitefinity project will run correctly, even though the new dll's aren't properly integrated in your solution and possibly "source control".
Unexpected behaviours of previously working elements
Secondly, I didn't test the frontend and backend during the different steps (Sitefinity versions within upgrade), but I tested everything once my solution had reached the last Sitefinity version. I thought I had checked everything, but it wasn't the case, and some of my custom Widgets didn't work properly on the latest version of Sitefinity. Next time I'll go more in detail on all custom parts, since from a working version of Sitefinity, you can end up with a newer version that breaks some behaviours. If you notice this, you might better wait a bit more for a fix, or the next release which might fix the problems.
Outside access to website during upgrade.
Furthermore, once you need to do the upgrade on the production database/website, the website shouldn't be accessed by people, since the upgrade of database might take some time.
Time needed for upgrading everything
One more thing I would like to add, it takes time to perform upgrade of several versions.
The first time I upgraded (I needed to go through 2 versions), and having to upgrade locally, to a development database, deploy the website on developement environment, then make it again on test. I took about 4 hours before everything was fully working. Make sure you have enough time, because it can be more tricky if you need to stop everything then come back to it.