My TFS build definition have started to add some extra overhead(Probably windows line endings) to some of the files that are included in my project. Any ideas as how to avoid this?
The files are used to update a linux machine that my application connects to. When I check in the file it is 1001 bytes in size and if i download it from TFS/git it is also 1001 bytes in size. After it is included in the build and installed the size of the file is now 1022 bytes in size.
If I build the project locally and installed it from there the size of the file is 1001 bytes.
We are running version 2017 (15.117.26714.0(Tfs2017.Update2))
It has worked in the past. Not sure if the TFS was updated or maybe the agent was changed.
Any ideas will be much appreciated.
Best regards
Kasper
Related
I looked up on the internet and it said courgette.log file is based on docker.
I am using Docker version 20.10.17, build 100c701 on Windows 11 Home.
But I have docker installed for a long time now. Why did courgette.log file appear today itself empty and with size: 0 bytes.
This is a well-known issue related to GitHub:
https://github.com/docker/for-win/issues/12468
courgette.log is created each time you're going to update Docker desktop.
Issue are reproduced on Windows 11 and Windows 10.
This log file is apparently created by an executable file called courgette64.exe into Docker installation folder.
Do not hesitate to remove it, it does not cause any side effects.
Chromium projects related links:
https://chromium.googlesource.com/chromium/src/courgette/+/HEAD
https://www.chromium.org/developers/design-documents/software-updates-courgette/
I'm working on a Linux system (a based of OpenWRT version) that has not much storage (<3MB) and no active internet connection, however I need to be able to publish to a MQTT-Broker some outputs. Is there a way for me to install just the publisher part of Mosquitto to save space or another way to solve this issue?
Without a LOT more information about the system this question is basically impossible to answer. e.g. we have no idea about what OS is being used...
But for a system with such tightly constrained storage your best option will probably to build the components you need from scratch that way you have complete control over what gets installed.
You could build the mosquitto tools and then strip them before copying just the binary you want (and any require libraries) to the system.
If you install from pretty much any Linux package management system you are likely to get all the tools plus man pages which will inflate the install footprint.
EDIT -
But all that said, a quick look at the available packages for OpenWRT implies that the existing packages that include both the broker and the command line tools would use 129kb (99 + 30 and is less if you don't need SSL 85 + 28) when installed (this assumes the pre-requisites are already installed)
https://openwrt.org/packages/table/start?dataflt%5BDescription_wiki*%7E%5D=mosquitto
I created a new .NET Core Console Application with Visual Studio 2017 (RTM). Then added Docker support and got the docker file + compose files just fine. However there are few issues with them.
Docker compose files have version 2 which makes the build fail to the following error message
Microsoft.DotNet.Docker.CommandLineClientException: client version 1.22 is too old. Minimum supported API version is 1.24, please upgrade your client to a newer version.
This can be fixed by manually changing the compose file versions to 2.1. (not sure if valid fix) Then you'll get another error message
MSB4006 There is a circular dependency in the target dependency graph involving target "DockerCleanServiceReferences".
This I have no idea how to fix. I know the error message is due to some configuration that causes circular reference (e.g. post build event that does build)
So, any resources or tips how to package the .NET Core console application into docker container manually? I'm just getting to know Docker so don't assume I know anything of it yet.
Another question, that is there some place where I could get updated versions of these Visual Studio templates or are these known issues?
It turned out the problem for me was having my DockerFile, SLN file, and CSPROJ file all in the same folder. You know how when you create a solution, it asks you if you want to create a subdirectory? If you do not, and your SLN and CSPROJ files share the same folder, inevitably the Docker files will be added to this same folder, creating the circular reference. If your SLN file lives in the directory above your CSPROJ file, the DockerFile et al will be put into your parent directory with the SLN file, and all will be well. This solved it for me.
Can you please check if your Docker for Windows is targeting Linux? It's likely you were targeting Windows container, which is not supported with .NET Core yet.
On my first spin of VS2017 with docker, using the default template, I ran in to the same issue.
I referred to this article - https://blogs.msdn.microsoft.com/containerstuff/2017/03/13/visual-studio-2017-client-version-1-22-is-too-old/
This is what worked for me - As recommended, made this changes in docker-compose project's docker-compose.ci.build.yml :
The 'version' parameter on the top of the file which was set to 2, was change to 2.1
Repeated the same changes on the other files in the project including:
docker-compose.yml
docker-compose.override.yml
docker-compose.vs.debug.yml
docker-compose.vs.release.yml
Regarding your question on how to package a .NET Core console application into a Docker image manually. The https://github.com/dotnet/dotnet-docker-samples are intended to answer that very question. Check them out. If you run into issues with them or have suggestions please log an issue (https://github.com/dotnet/dotnet-docker-samples/issues).
Thanks for the post. We will be adding Nano Server container tooling "soon". Until then, you can work with Linux containers which will give a similar experience.
I'll be reinstalling Windows and I wondered if there's a way to backup/restore Delphi license info so I don't "lose" one of my installations for that.
In other words - is there a way to uninstall Delphi, reinstall Windows, reinstall Delphi without that being treated as a "new" installation?
[I want to completely wipe out my computer and start out from scratch. I'll be reinstalling XE5, XE7, and 10 Seattle.]
The .slip files used for registration info are in C:\ProgramData, in either the CodeGear or Embarcadero folders depending on which version of the IDE you're using.
I've successfully copied the files from these folders to a thumb drive and moved them to a new computer. Note that part of the registration information is the local computer name, so in order to work on a different machine (or a clean Windows install on the same machine) the computer name needs to stay the same. Just name the computer the same, copy the .slip files to the same location on the new machine, and then install Delphi/RAD Studio.
To be on the safe side, I always copy the entire folder (including all subfolders and their contents) to make sure I've gotten everything the IDE needs.
I had a similar problem when renaming my Windows 10 computer. Apparently the license is bound to the computer name. I had to re-register Delphi after renaming my computer but failed because of the limit of my license key.
Solution was renaming back my computer and renaming C:\ProgramData\Embarcadero\.cgb_license.corrupted and C:\ProgramData\Embarcadero\.licenses\.cg_license.corrupted to files without the .corrupted as suffix. My licence slip file was C:\ProgramData\Embarcadero\.2016_2.#############.slip.
I made an application with ADO Component and connect to Oracle with it, I don't have any problem when I run it in another machine.
But, when I use ODAC component and TOraSession and connect with it via Direct Connect and run it in another machine I faced to this error:
The Program Can't Start Because dbrtl70.bpl is missing from your Computer. Try to re installing the Program to fix it
As I investigate, dbrtl70.bpl is Delphi package file in System32 folder.
I want to know how can I solve this problem.
I'm going to take a wild guess and suggest that you have a 64 bit machine. You've copied the .bpl files into the 64 bit system folder (System32) where your 32 bit Delphi 7 program cannot see them. Put them in the 32 bit system folder (SysWOW64) instead and all should be well.
To learn more about the issue, read up on the File System Redirector.
If you don't want runtime packages, and all your dependencies support being built without using runtime packages, then simply uncheck the use runtime packages option.
My app was asking for a .bpl package when run on other machines.
Cancelling 'link with runtime packages' didn't solve it until I deleted the runtime packages listed in 'runtime packages'. Then it was OK.