I'm using an on-premises VSTS build agent to build and release my application. The retention configuration for the release is set to 30 days, and in the VSTS web site I can see there are 30 days worth of releases retained. However, I was expecting to see the .zip files for the retained release somewhere in the build agents working folder, but cannot find them anywhere.
Can someone tell me where the releases are stored?
The VSTS releases stores in team services server and you can only access through Releases Tab.
If you want to retention the release earlier then 30 days, you can specify Days to retain a release with bigger number between 31 and 365.
As Days to retain a release option description:
Set the number of days to retain a release deployed to this
environment. Any release can be retained for at least 1 day and a
maximum of 365 days.
If you want to view the artifacts related to a release, you can publish build artifacts to a network shared path. In the related build definition, select Artifact Type as File share for Publish Build Artifacts task. So the artifacts will always be retained locally.
Related
We have an Access Database-Solution with Frontend and Backend Database running for years.
Now within the last two days problems occurred. E.g.
Set db = DBEngine.OpenDatabase(strDatabasePath, False, True, "MS Access;PWD=" & strPassword)
Does result in Error 3050 - File could not be locked. ONLY when the Backend Database is on a network share (if it's on a local drive everything works as expected).
The error occurs on any share:
a Shared Folder from a Windows PC
a Shared (Samba) Folder on a NAS
independently whether the share is accessed via a UNC-Path (\server\share) or a mapped drive-path.
The error was introduced by a faulty Office Patch (seems it was V2111 - 14701.20240)
In the first version of this post I thought that Windows-Update KB5008212 was causing the problem.
Thanks to #Gustav for identifying the problem.
How do we find out WHEN MS pleases to fix the problem?
From Microsoft:
This is due to today’s (Patch Tuesday) update to Office. The problem
was introduced by a security fix, so it impacts all active versions of
Access. We are working on a fix, and will deliver it as quickly as
possible.
The update has only been set to automatically update a very small
percentage of users, and it looks like we will be able to pause
automatic updates, so it will not propagate.
There will be a page added to the
Fixes or workarounds for recent issues in Access (microsoft.com),
which will then be the place to go
for updates.
These are the updates that introduced the problem:
KB 5002104 for Office 2013
KB 5002099 for Office 2016
Office 2019 Version 1808, build 10381.20020
Office LTSC 2021 Version 2108, build 14332.20204
Microsoft 365 Apps:
Current Channel Version 2111, build 14701.20248
Monthly Enterprise Channel Version 2110, build 14527.20340
Monthly Enterprise Channel Version 2109, build 14430.20380
Semi-Annual Enterprise Channel (Preview) Version 2108, build 14326.20692
Semi-Annual Enterprise Channel Version 2102, build 13801.21086
Semi-Annual Enterprise Channel Version 2008, build 13127.21842
If you did get updated to one of those builds, the only solution
currently is to move back to an earlier build in the channel.
Installing version 2008, in fact, resolved the issue for me. Microsoft just released new builds of versions 2108 and 2112 yesterday, 01/11/2022, that also resolved this same issue for me.
We had the same problems.
Uninstalling Office 365 (32-bits) and re-installing Office 365 (32-bits) from the OfficeWeb-Portal seems to solve the problem.
Ours is not manifesting in the same way. I seem to get a lot of orphaned lock files. Users are having some problems getting in to the databases but usually If I delete the lock file and have them wait 5 minutes, the problem goes away. Since this started it has been a game of running daily backups to a separate file just in case. Major Pain in the you know what. I'll keep an eye on what crops up here. Thanks folks (Yes this is more of a comment than an Answer, but I needed more characters)
We have an Access Database-Solution with Frontend and Backend Database running for years.
Now within the last two days problems occurred. E.g.
Set db = DBEngine.OpenDatabase(strDatabasePath, False, True, "MS Access;PWD=" & strPassword)
Does result in Error 3050 - File could not be locked. ONLY when the Backend Database is on a network share (if it's on a local drive everything works as expected).
The error occurs on any share:
a Shared Folder from a Windows PC
a Shared (Samba) Folder on a NAS
independently whether the share is accessed via a UNC-Path (\server\share) or a mapped drive-path.
The error was introduced by a faulty Office Patch (seems it was V2111 - 14701.20240)
In the first version of this post I thought that Windows-Update KB5008212 was causing the problem.
Thanks to #Gustav for identifying the problem.
How do we find out WHEN MS pleases to fix the problem?
From Microsoft:
This is due to today’s (Patch Tuesday) update to Office. The problem
was introduced by a security fix, so it impacts all active versions of
Access. We are working on a fix, and will deliver it as quickly as
possible.
The update has only been set to automatically update a very small
percentage of users, and it looks like we will be able to pause
automatic updates, so it will not propagate.
There will be a page added to the
Fixes or workarounds for recent issues in Access (microsoft.com),
which will then be the place to go
for updates.
These are the updates that introduced the problem:
KB 5002104 for Office 2013
KB 5002099 for Office 2016
Office 2019 Version 1808, build 10381.20020
Office LTSC 2021 Version 2108, build 14332.20204
Microsoft 365 Apps:
Current Channel Version 2111, build 14701.20248
Monthly Enterprise Channel Version 2110, build 14527.20340
Monthly Enterprise Channel Version 2109, build 14430.20380
Semi-Annual Enterprise Channel (Preview) Version 2108, build 14326.20692
Semi-Annual Enterprise Channel Version 2102, build 13801.21086
Semi-Annual Enterprise Channel Version 2008, build 13127.21842
If you did get updated to one of those builds, the only solution
currently is to move back to an earlier build in the channel.
Installing version 2008, in fact, resolved the issue for me. Microsoft just released new builds of versions 2108 and 2112 yesterday, 01/11/2022, that also resolved this same issue for me.
We had the same problems.
Uninstalling Office 365 (32-bits) and re-installing Office 365 (32-bits) from the OfficeWeb-Portal seems to solve the problem.
Ours is not manifesting in the same way. I seem to get a lot of orphaned lock files. Users are having some problems getting in to the databases but usually If I delete the lock file and have them wait 5 minutes, the problem goes away. Since this started it has been a game of running daily backups to a separate file just in case. Major Pain in the you know what. I'll keep an eye on what crops up here. Thanks folks (Yes this is more of a comment than an Answer, but I needed more characters)
There are several questions on StackOverflow about the same topic, but I haven't found the solution.
In my Windows Phone 8 App I store user settings in the IsolatedStorage.ApplicationSettings.
This works great, I use IsolatedStorage.ApplicationSettings[key] = value to set my values and ofcourse use IsolatedStorage.ApplicationSettings.Save() to save them.
I have also created a database using a .sdf file to save local data.
When I use the Deploy function in VS2013(Visual Studio 2013) to update my app, the isolated storage settings will remain.
However, when I have used the Rebuild or Clean function in VS2013, the isolated storage will be whiped on the next deploy! Resulting in the deletion of all local data and usersettings.
Why does this behavior occur?
A work-around would be to not use these functions, I could basically do all my work from development to deployment without using Rebuild or Clean. But when I would (accidentally) use these functions I would be unable to deploy without whiping all local data on the devices.
This behavior also occurs when I upload my App to the Windows Phone Beta Store. (I haven't used the live store yet)
UPDATE:
Thanks to robwirving I have some new insight: XapDeployCmd.exe
This is a tool that can perform all the deployment tasks that Visual Studio normally does for you, in command prompt. The relevant actions are installlaunch and update.
I think VS performs an installlaunch action when the deployment process detects the project has been rebuild. However, if I use the update action with XapDeployCmd on a Xap build by Visual Studio, which has been Cleaned and Rebuild, the isolated storage is NOT whiped.
Could it be that the Windows Phone Beta Store mimics this behavior?
The default behavior of Visual Studio is to do a fresh install instead of an update when it has detected a rebuild. As far as I know this is not configurable.
You could do a rebuild and then update your XAP without deploying through Visual Studio however. Here is the documentation for XapDeployCmd, a command line tool included in the Windows Phone Dev tools that allows you to install or update a XAP from the command line. http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff402565%28v=vs.105%29.aspx
When You perform Clean Solution Visual Studio Cleans all the data related to Project and all related linking to the .dlls and other linked data. It serves as cleaning of all Generated files and data so Ultimately you loss your local data.
In the Case of Rebuild Solution Visual Studio Regenerates files and data that you are using with that Solution so In the Process of Regenerating your data and linking of .dlls also get cleared and new solution for that Project is Created so here you also loss Your data
In Short, The Process of Clean Cleans the Whole Solution linking and data while Rebuild regenrates the new solution after cleaning the data and linkings.
I've created a split Access database application and used the packaging wizard to create a deployment package. All the files are installed by the deployment package into C:\Documemts and Settings\All Users\Application Data\Provision Manager, this is too avoid Windows Vista not allowing write access to the Program Files directory.
The application installs OK on both Vista and XP and creates a Provision Manager entry in the Program Group in the user account that installed the application, however when I login using another account (both Admin and non-admin ones) the there is no Provision Manager item listed in the Program Group.
Can anyone enlighten me as to what is going on here and more importantly how I can ensure that the deployment package creates a Program Group item for each user account.
Thanks
Marc
To ENSURE that the package has created the right Program Group, look in All Users/Start Menu/Programs because these programs are automatically placed in every user's Start Menu when they log in. Similar for Desktop shortcuts, place them in All Users/Desktop
The fundamental problem (and it's not really a problem but a feature) is that MS tightened up security in Windows Vista. Users are no longer allowed to update the All Users Start Menu/Programs or Application Data folder. Only administrators can update such as using instllers. Now that's mostly fine for the shortcuts to Access FEs. The real problem arises with the FE MDB/MDEs as users pretty much have to have read/write/create/delete (although strictly speaking create/delete privilieges are only required for LDB files.) So those can't be installed into the All Users folders.
The solution is to split the runtime install into two components. The administrator types install the actual Access runtime into Program Files along with msaccess.exe , etc, etc.
Then you have a second install with the users can run which puts the Access FE MDB/MDE, and other files in the Current Users Applications Data folder along with shortcuts on the desktop.
If the users are on your local LAN you could use the free Auto FE Updater utility to handle the FE installation for users.
If the users are remote then you can use the Sample inno script which checks to see if a version of Access is installed. If not it tells you to install a runtime version of Access. If installed then it continues to install your FE MDE and other assorted files.
http://groups.google.com/group/microsoft.public.access/msg/10e3fc9234660872?hl=en
Sample inno script which "wraps" the package wizard install into a single .exe
Deploying updates to your software in a Runtime environment for Access 2007
I have a .NET application which uses an accdb file (MS Access 2007 format) as its database. To install this app on another machine I need to install the Access engine on that machine. Microsoft has this file: AccessDatabaseEngine.exe which includes the engine, but when extracted during installation, runs another .msi installer.
As you can guess, since this msi is run during the installation of another msi (my app's installer) the Access engine setup fails with error 1500: "Another installation is in progress. Finish that one before continuing this one..."
I found the Runtime for Access 2007 as well, and it does install the engine, but the Runtime package is again an msi installer which means I'm still having the same problem.
Any ideas to include the engine in my app's installer?
You probably want to have a look at this article: Adding Programs to Access 2007 Deployment Packages
The Access Developer Extensions offer a basic but functional installer that can take care of the general deployment scenarios.
The best think would be to build your own msi pack including needed access files. You could use a product like VERITAS Wininstall. You have this "Discover" method that allows you to build a fully operationial .msi file by (1) taking 2 snapshots of your system (one before the installation, one after) then (2) creating the .msi file corresponding to the installation process.
Anyway, I'd advise you to have multiple packs, one for Access, that can be installed with a "for all users" option when the computer joins your company's domain, one for your app. By doing so you will be able to distribute new versions of your app without redistributing Access, which takes a few mega of space as well as a few minutes of user's most precious time).
Sio if Microsoft already delivers an Access Runtime msi package, just keep it 'as is' and distribute it automatically on your network when a new machine joins the domain.
I wouldn't recommend WinInstall, we have it in my office and we have to keep calling them in to package stuff for us as it's so finiky to use. Some things they haven't been able to package at all. WISE Studio is better or a free alternative is AppDeploy whihc I have heard great things about.
I found this software called "Bootstrapper Manifest Generator" or BMG. It helps create a prerequisite package using an MSI or EXE installer file, and adds it to VS2008 Prerequisites dialog box in Setup and Deployment projects. Although it's not that user friendly, it does the job. It's on MSDN: code.msdn.microsoft.com/bmg
Thought it's good to save others from going through all the trouble.