Dotnet variables about al-go HOT 10 CLOSED

Hi,
I'm just doing this:

Param([Hashtable]$parameters)
New-BcContainer @parameters
$script = {
    $dirOrigen = #Place here the path to \.netpackages
    $dirDestino = "C:\Program Files (x86)\Microsoft Dynamics NAV\190\RoleTailored Client"
    $dirServicio = "C:\Program Files\Microsoft Dynamics NAV\190\Service\Add-Ins"
    Get-ChildItem -Path $dirOrigen | Copy-Item -Destination $dirDestino
    Get-ChildItem -Path $dirOrigen | Copy-Item -Destination $dirServicio
}
Invoke-ScriptInBcContainer $parameters.ContainerName -scriptblock $script

Hope this help

from al-go.

AL-Go for GitHub might not be the best fit.
Especially, if you are planning to stay on BC 19 - and use dotnet framework DLLs etc.
You can probably make things work using script overrides etc., but you will be using AL-Go for something that it isn't really intended for.

from al-go.

Ok, thank you anyway

from al-go.

If the goal is just to allow dotnet variables, you can probably just set "EnablePerTenantExtensionCop": false in the repo settings file and then the cop is disabled.
Onprem can however pull many other things along.

from al-go.

Hi,
We already have done so, but we need to use our own dll’s, “move” them to the assembly-probing path in the container. We understand that al-go is not intended for that but, once you taste it, is hard to get rid of its advantages :). Is a big client and it will help a lot if we can run the “CI/CD” workflow incrementing version numbers, checking that we don’t break anything, … and the “Create release” one in order to have it well organized.

from al-go.

Thinking about it (and if other people find this), you could create a file called NewBcContainer.ps1 in your .AL-Go folder.
This will override the container creation and in that script, you can copy your DLLs into the container.

The NewBcContainer function looks like this (without the comments):

Param([Hashtable]$parameters)
# here you could add other parameters to New-BcContainer
New-BcContainer @parameters
# here you could copy files into the container
Invoke-ScriptInBcContainer $parameters.ContainerName -scriptblock { $progressPreference = 'SilentlyContinue' }

Note though, that as we change AL-Go in the future, overrides like these are sometimes broken and you might have to change things.

from al-go.

Thank you we'll try it

from al-go.

We have already tried it and it works fine,

Thanks.

from al-go.

Hi @amunoz-ldr ,

would you mind to share your solution?

I've tried similar with the solution provided by Freddy, but I can't seem to get it working.

I created in the".Al-Go" directory an file called "NewBcContainer.ps1", at first I wasn't sure if it gets executed so I tried some less useful commands to get an "reaction" in the shape of an error. For example:

Param([Hashtable]$parameters)
# here you could add other parameters to New-BcContainer
New-BcContainer @parameters
Remove-BcContainer -containerName $parameters['containerName']

It seems that there is some error handling to prevent something like this? @freddydk .

The following script is the one that is the result after some hours of trial and error

Param([Hashtable]$parameters)
# here you could add other parameters to New-BcContainer
New-BcContainer @parameters

# here you could copy files into the container
$DependencyFolder =  ${github.workspace} + "/.netpackages"

Get-ChildItem $DependencyFolder -Filter *.dll | 
Foreach-Object {
    Copy-Item -Path $_.FullName -Destination "C:\Windows\Microsoft.NET\Assembly\"
}

Currently, copying the dlls to the service tier is no concern due to setting in the AL-Go-Settings.json "doNotPublishApps": true

from al-go.

Thanks for providing your solution!

Unfortunately I still get an error when compiling the app, I think the DLLs are not yet recognized when compiling in Visual Studio Code. @freddydk , do you have any input for me on how this can be done?

from al-go.