I have two TeamCity Servers which are running on different software versions: one server is running "TeamCity Enterprise 9.1.7" whereas the other Server is running "TeamCity Professional 7.0.2". What is the best way to perform a migration. I want to transfer the projects that exist on Server 7.0.2 to the Server 9.1.7.
I would be very grateful if you could provide me with the steps to undertake.
There are a lot of TC versions between 7.0.2 and 9.1.7, more than 4 years of updates: https://confluence.jetbrains.com/display/TW/Previous+Releases+Downloads
First of all, you should make a backup using maintainDB tool, then you can try to migrate from major to major version and test the results:
UPDATE: base on vlad-p53's comment you can migrate directly form 7.0.2 to 9.1.7, so, just follow the tutorial A Step by Step Guide to Migrating a TeamCity Instance from One Server to Another.
7.0.2 to 8.0 and test the results.
8.0 to 9.0 and test the results
9.0 to 9.1.7
If a migration to a major version does not work, you can try a previous versions and repeat the process.
Each release has a release note that explains if there is a migration issue, I recommend to you to read them.
To each migration you can follow the steps of this tutorial: A Step by Step Guide to Migrating a TeamCity Instance from One Server to Another.
Related
We have an .Net 6 API.
We have our own Nuget server to ensure we have backup of used Nuget packages so we always are sure we can run our CI chain.
After the upgrade to .Net 6, then every time MS publishes a new version of any of these three assemblies then our CI builds fail, because our NuGet server doesn't have the new version.
Microsoft.NETCore.App.Runtime.win-x64
Microsoft.AspNetCore.Runtime.win-x64
Microsoft.WindowsDesktop.Runtime.win-x64
Latest with 6.0.8. We then have to download the new packages to our Nuget server and then everything works.
In general I would like us to keep on known versions all the time, and only change referenced package version on purpose - and not just because developers publish new versions.
But I can't find any explicit references to these three packages.
Does anyone know where they come from - and more importantly - are there any way to lock our solution to use e.g. 6.0.8, until we decide to upgrade next time?
Best regards
/Anders
I have some problem with self-hosted Integration Runtime in Azure Data Factory V2.
I have a few VMs running 4.X.X IR software. Some of them had auto update enabled in DFv2
There was an update from 4.X.X to 5.X. After this, IR is unavailable from DFv2.
Looks like the IR services running on the VMs are pointing to a wrong execute path - using still 4.0. I can fix it manually with sc config or reinstall IR, but after reboot it doesn't work again.
Is that a bug? Can I somehow fix it without removing the VMs?
Update:
What I did - I went to Data Factory V2 Integration Runtimes and picked my self-hosted IR, went to Auto update and enabled it. My Virtual Machine hosting this IR was running an older IR software (4.X.X). There was an update to 5.X.X. Everything was working fine until I rebooted the VM. After this from Data Factory V2 Integration Runtimes I was seeing an error saying that my self-hosted IR is unavailable. I logged into the hosting VM and it turned out that IR software cannot start its service dmgsvc.exe. When you go to services.msc and check the Integration Runtime service pointing to the dmgsvc.exe, the path will be incorrect. What was wrong there? It was a catalog 4.0 instead of 5.0. IR software cannot start up correctly because of that and the error is Error 2: System cannot find the file specified. So what I did? I manually fixed it and it was working. But after the first reboot of the VM it was again pointing to the 4.0 catalog. I reinstalled the software and the effect was the same.
For the upgrade to version 5.x of the Azure Data Factory self-hosted integration runtime, we require .NET Framework Runtime 4.7.2 or later. On the download page, you'll find download links for the latest 4.x version and the latest two 5.x versions.
If automatic update is on and you've already upgraded your .NET
Framework Runtime to 4.7.2 or later, the self-hosted integration
runtime will be automatically upgraded to the latest 5.x version.
If automatic update is on and you haven't upgraded your .NET
Framework Runtime to 4.7.2 or later, the self-hosted integration
runtime won't be automatically upgraded to the latest 5.x version.
The self-hosted integration runtime will stay in the current 4.x
version. You can see a warning for a .NET Framework Runtime upgrade
in the portal and the self-hosted integration runtime client.
Refer: Troubleshoot self-hosted integration runtime
I want to migrate DataStage projects 11.3 to 11.7, I was wondering what problems there may be at the time of migration.
If you are using all the latest Stages/Connector in V11.3, you shouldn't hit any issues and it should be a simple export/import.
However, if you use some deprecated stages then you need to run the Connector Migration Tool to replace them - https://www.ibm.com/support/knowledgecenter/en/SSZJPZ_11.7.0/com.ibm.swg.im.iis.conn.migtool.doc/topics/connectormigrationtool_intro.html
You also need to check whether all the Source and Target you are using are still supported, e.g. Oracle Connector for V11.3 support Oracle 10gR2, 11gR1 and 11gR2 while V11.7 only support minimum of 11gR2.
When development is finished and TFS (VSTS) takes over. The build completes successfully and the artifact directory contains the published website via a build definition. The Release Manager is then triggered, and takes over and creates a website in an environment, the website files are copied to the environment and the website started. All good so far.
Missing the Database migration steps here...
Now someone starts the server and it fails because the database has not been migrated. How do we do that? The EF Tools were not copied to that environment, in fact we can't even run dotnet.exe because the core sdk has not been deployed onto that environment either. so even if we had the tools, we can't execute them.
In EF 6.x it was easy cause we could just copy migrate.exe as part of the artifacts, and run that on the environment after the files were copied. As I understand it, the EF Tools are now a DLL (ef.dll) that has to be run by dotnet.exe. Does this mean that all web servers now need Core SDK to perform migrations?
Other details about my project setup:
asp.net.core application being deployed onto a QA server for testing. This is not a dev box, does not have VS2015 installed, does not have Core SDK installed.
Update: EF.EXE is part of preview3 and 4.
This solves the requirement for "dotnet.exe" being installed. I can copy that into the artifacts drop like I used to with migrate.exe. Is this the proposed solution by the EF Team?
EF.EXE is part of preview3 and 4.
This solves the requirement for "dotnet.exe" being installed. I can copy that into the artifacts drop like I used to with migrate.exe. Is this the proposed solution by the EF Team?
Yes. Do this.
Also see issue #6313 where we want to make this experience a little easier on .NET Core.
In order to run .NET Core web application on your server, you need to install .NET Core SDK (currently 1.1) on your servers. Doing so will give you the dotnet command so that you can execute dotnet ef database update on your server environment to update the database to a specified migration.
I am required to create a simple application. Since I am good at WPF and I don't know win forms that good I implemented my application by creating a .Net Framework 4.0 WPF project in Visual Studio. Everything works great the application runs like it is supposed to.
Since the application is required to run in multiple platforms (Windows XP and above) I am including the prerequisites when publishing my applications. The prerequisites happen to be:
1) WIC (Windows Imaging Component) old computers need that to run the .net framework 4.0
2) Windows installer 3.1 (needed in order to install the next prerequisite)
3) Windows .NET Framework 4.0 Client Profile
If I install those prerequisites then the application runs like it is supposed to.
Now the problem is:
My boss did not approve my application because he tried installing it in a Windows XP machine with SP2 and this are the things that happened:
Step 1)
// first prerequisite (WIC) took less than 1 minute to install everything
// is working great so far.
Step 2)
// second prerequisite (Windows Installer 3.1) takes about 2 minutes to install
// which is great. After the installation is done the computer needs to be
// restarted in order to continue with the installation. Things are not going
// that good now but we are still ok...
Step 3)
// After the computer is done rebooting it continues with the last prerequisite
// (Windows .NET Framework 4.0 Client Profile). That takes 10 minutes to install!!!!
Step 4)
// My application has all the prerequisites needed to be installed so it installs in
// about 1 minute
We recorded the time, and the application took about 25 minutes to install from start to finish. The computer where we tested the installation was a virtual computer using 2 cores and 1 GB of memory with 3.1 GHZ.
What do you guys recommend in order to speed up this installation? Should I use a different technology such as windows forms using .net 2.0? It will be nice if I can deploy the application that I have already created. If you guys could help me make this application portable I will really appreciate it. In order to do so I tried building my application with all the required references copied to the output directory. That did not work... Or any ideas of how to make the installation be faster will be of great help as well.
If you're using .NET Framework 4.0 (which is not going to come out-of-the-box with any versions of Windows, especially Windows XP) there's no way to get around the install of .NET 4.0 on the target machine. Your major bottleneck is going to be the download of .NET 4.0 files from Microsoft to the machine.
I've run into similar problems where the initial install of an application takes forever because of the .NET 4.0 download and install. We even encountered an issue where the application couldn't be install because there was insufficient disk space for the download.
One option would be to pre-push the prereqs out to all the machines you'll be install this on before deploying your application.
Otherwise, you might be forced to use an older version of the .NET framework. Here's a list of the framework versions which shipped with various versions of windows.
http://blogs.msdn.com/b/astebner/archive/2007/03/14/mailbag-what-version-of-the-net-framework-is-included-in-what-version-of-the-os.aspx
Unfortunately, if your organization is committed to using a 10 year old operating system then they either need to accept that modern tools will require a lengthy install process while all prereqs are loaded... or else force you to use a 10 year old software technolgy.