You Tube Channel: www.youtube.com/@bramanareddy0482

  When using 3rd party libraries, sometimes they let out a new version. And sometimes that new version breaks something that used to work in the old version, but also adds features you need. So you found yourself having to use one method from the old version and another from the new version of the same library. There are two problems here: It won’t compile. Both libraries have the same namespace, causing ambiguity the compiler can’t handle. It won’t run. The referenced DLLs are copied to the output dir, but because they have the same name, they will override each other, and will cause the runtime loading of the assembly to have a version mismatch. Welcome to DLL hell. The solution Let’s take my client’s project as a practical example. The project was using a 3rd party library by Winnovative Software, for handling pdf operations. The new version of the dll broke some specific functionality that had to be supported. The DLL name:  wnvhtmltopdf.dll  The old version: 14.2 The new version:

YAML  Ain't Markup Language ( YAML ) is a serialization language that has steadily increased in popularity over the last few years. This blog provides a basic overview of correct YAML syntax, which is how Ansible playbooks are expressed. We use YAML because it is easier for humans to read and write than other common data formats like JSON or XML.  also, there are libraries available in most programming languages for working with YAML. YAML Basics  For Ansible, nearly every YAML file starts with a list. Each item in the list is a list of key/value pairs, commonly called a “hash” or a “dictionary”. So, we need to know how to write lists and dictionaries in YAML. There’s another small quirk to YAML. All YAML files (regardless of their association with Ansible or not) can optionally begin with  ---  and end with  ... . This is part of the YAML format and indicates the start and end of a document. All members of a list are lines beginning at the same indentation level starting with a 

How Ansible works?  Ansible is a software tool that provides simple but powerful automation for cross-platform computer support. It is primarily intended for IT professionals, who use it for application deployment, updates on workstations and servers, cloud provisioning, configuration management, intra-service orchestration, and nearly anything a systems administrator does on a weekly or daily basis.  Ansible doesn't depend on agent software and has no additional security infrastructure, so it's easy to deploy. In Ansible, there are two categories of computers: the control node and managed nodes. The control node is a computer that runs Ansible. There must be at least one control node, although a backup control node may also exist. A managed node is any device being managed by the control node. Ansible works by connecting to nodes (clients, servers, or whatever you're configuring) on a network, and then sending a small program called an Ansible module to that node. Ansible

Playbooks are written in yaml format, and you can actually choose where to store your playbooks. In my case I’ll create a folder called playbooks for storing my playbooks, and I’ll create this in the root user’s home directory: [root@controller ~]# pwd /root [root@controller ~]# mkdir playbooks [root@controller ~]# cd playbooks [root@controller playbooks]# pwd /root/playbooks In this directory, I’ll then create a yaml file called HelloWorld.yml ---  - hosts: all    tasks:    - name: Create a file called '/tmp/testfile.txt' with the content 'Hellow World-BRR'      win_copy:        content: hellow world-BRR        dest: c:\temp\testfile.txt This playbook is designed to create the file /tmp/testfile.txt on the client ansibleclient01.local using ansible’s  copy module . You can think of this playbook as a script that you can execute. You can execute this playbook using the ansible-playbook command: PLAY [all] *****************************************************************