On previous projects I've used Nant but want to try out Rake on a new project. With Nant I used the Version task in nantcontrib that generates a Version number for you. Is there anything similar out there for doing this using Rake?
Jeweler provides rake tasks for Major.Minor.Patch version changing. It is designed for managing Gems, but I've used it in other non-gem projects purely for the version management features.
Related
We have an on-premises Azure DevOps 2019 server, with build pipelines for numerous .Net 4.x solutions that our small team maintains using VS2019.
The team is about to upgrade to VS2022, and at some point I would like to migrate some solutions to .Net 6. Can DevOps 2019 build .Net 6 solutions, and if so what changes are needed to support this (such as presumably installing VS2022 on the server)?
Will those solutions' build pipelines require any changes or should they continue to work as-is? They don't contain anything too clever, with steps such as: NuGet restore, build solution, run unit tests, NuGet pack & push. (The build pipelines are managed via the web GUI, not YAML, if that makes a difference).
Some solutions will remain .Net 4.x, so the server will still need to support (build) these.
You should just need two things:
First you have to install the corresponding SDK for building the apps (see sdk download - Build apps - SDK) on your build-agents.
(Optional) Add or modify your set SDK Task in your pipelines (see use dotnet core task).
One more hint, you don't need to install a whole VS on the server. The Build-Tools are enough (VS2022 Buildtools preview).
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 changed the Gallio.NUnitAdapterLatest.plugin with a binding redirect to this : oldVersion="2.6.0.0-3.0.5813.39032".
I also overwrote tje previous dlls in the latest subfolder.
I changed all occurences in the config file to no avail.
I also debugged the source code but did not manage to make it take my dlls.
What itches me is "compatiblity" between 2.6.x and 3.0 of nunit since as I read it somewhere, this trick can only be done if compatibility between the two dlls are maintained, which I am not sure.
I compiled Gallio in X86, for a .Net 4 test project.
Any ideas ?
I very highly doubt that you will get NUnit 3.0 running under Gallio's adapter. NUnit 3 is a nearly complete rewrite and it's engine is not at all compatible with the 2.6 core.
In order to get it working, you will need to create a new NUnit3 adapter for Gallio. Since Gallio is a dead project, I wouldn't expend the effort. Gallio's test runner is nice, but why are you still using it to run NUnit tests?
I just upgraded to version 3.0.1 from nunit 2.6.4. It used to have a NUnit Gui Runner, located here:
After installing 3.0.1 (which I downloaded windows version from here)
I now no longer see the nunit.exe in the installation folder, for example the directory structure is different and appears to be missing many files that were part of the previous installation:
The NUnit team decided to make the GUI a separate product and will be releasing it separately. It is being rewritten from the ground up for NUnit 3, but hasn't been released yet. Development is happening on the GitHub page at https://github.com/nunit/nunit-gui if you want to get involved or track the progress. Initial releases will be out soon.
Update - There have been several preview releases of the new NUnit GUI that can be found at https://github.com/nunit/nunit-gui/releases. The previews are not recommended for production use, but they work and can be used.
The "final" release is here, you can find it at: https://github.com/TestCentric/testcentric-gui/releases
For anyone coming to this page, looking where to find the NUnit Gui, please note that on http://nunit.org/?p=download you can get version 2.6.4, which does contain the Gui.
UPDATE
As pointed out in the comments, a lot has changed since, and you should no longer use the 2.x version tools, rather use the new TestCentric UI found at https://github.com/TestCentric/testcentric-gui/releases
I'm sketching an application deployment process for a bunch of relatively complex desktop applications. We have both native and Java apps, so the deployment must be able to check for existence of the JRE and install it if needed. Some of the apps depend on special hardware, so the deployment must also be able to launch the necessary driver installers. Some of the apps are multiplatform, and preferably the same mechanism should be able to create Windows, Linux and Mac OS X installers. That is:
The installer must be able to install, in addition to the application itself:
Java Runtime Environment.
Drivers (hardware) - that is, launch other installers.
The installer builder must be operable from the command line so that it can be integrated with an automatic build mechanism that generates installer packages for each platform as nightly builds.
In addition, I need to create "update from the web" mechanisms for the applications. It could be included in the installer, or it could also be a separate custom mechanism built into the application.
Now, this is getting a bit complex, and I suspect that there might be no single installer that could do this all. Therefore I'm thinking between two fundamentally different approaches:
Platform-specific mechanisms: NSIS would create .exe or .msi for Windows, XXX would create .deb for Ubuntu, and YYY would create .dmg for OS X.
Cross-platform installer that would handle all the requirements above: ZZZ?
Any recommendations? Some options that I've looked include:
NSIS - Excellent, but Windows only.
IzPack - Good, but requires JVM to run.
Is there an universal tool for this, or should I just pick an appropriate tool separately for each platform? In the latter case, what would be "NSIS equivalents" for Ubuntu and Mac OS X?
I have some recommendations as follows.
Use WIX (Windows Installer XML) for creating MSI installers for Windows
Use Package Maker (part of XCode tools) on MAC OS X, preferably the command line version
Write wrapper scripts (in Python or so) to drive the over-all installer creation process.
to aggregate all the components you need to install (may be from ur version control system)
generate necessary files for Wix and Package Maker as much as possible
to run the packaging tool and generate the package
Make sure that the overall installer creation process is a simple one command operation overall (with options to create different versions of your package based on criteria like release branch etc.)
Overall, developing this workflow requires some initial effort and quite a lot of thinking. But the end result is quite worth the effort.
I haven't done this on the Linux side, but I guess would use RPM/DEB on that front in this workflow.
BitRock InstallBuilder meets all the requirements, including being multiplatform and providing an autoupdate mechanism
You should take a look at InstallJammer. It will definitely handle the cross-platform elements that you want and can even add entries to the DEB and RPM databases on the target system during installation. OS X support is still experimental, but it mostly works.