Episode 354: In the Dynamics Corner Chair: Sweetening Your BC Development with NuGet not Nougat

WEBVTT

00:00:00.580 --> 00:00:03.108
Welcome everyone to another episode of Dynamics.

00:00:03.108 --> 00:00:07.269
Corner Is nougat a candy in a package.

00:00:07.269 --> 00:00:08.884
I'm your co-host, chris.

00:00:09.326 --> 00:00:09.968
And this is Brad.

00:00:09.968 --> 00:00:13.128
This episode was recorded on December 20th 2024.

00:00:13.128 --> 00:00:20.809
Chris, chris, chris, finishing the year, up coming into the holiday season, I think of that nougat, nougat in a candy.

00:00:20.809 --> 00:00:22.486
It's a holiday candy, isn't it?

00:00:22.486 --> 00:00:24.321
I think I don't even know.

00:00:24.321 --> 00:00:29.626
You have to ask ChatGPT or some of these other models to see exactly what a NuGet is.

00:00:29.626 --> 00:00:40.216
But today we had the opportunity to learn all about NuGet and how it can help a business central developer or an ISV within the lifecycle of the applications.

00:00:43.380 --> 00:00:45.405
With us today, we had the opportunity to speak with Chris Krieg.

00:00:45.405 --> 00:00:49.112
I was going to make a comment that Chris Krieg sounds like Kris Kringle.

00:00:49.112 --> 00:01:06.209
I was going to say that during the episode who brought in a candy called Nougat on a Christmas gift.

00:01:06.230 --> 00:01:07.611
Good afternoon, good morning.

00:01:07.611 --> 00:01:08.634
How are you doing, sir?

00:01:08.634 --> 00:01:09.855
Great, how about you?

00:01:09.855 --> 00:01:12.224
Excellent, excellent.

00:01:12.224 --> 00:01:14.608
I'm a little tongue-tied this morning for some reason.

00:01:14.608 --> 00:01:15.490
I guess it's just.

00:01:15.691 --> 00:01:16.620
It's Friday, it's.

00:01:16.659 --> 00:01:18.343
Friday and for the most of us.

00:01:18.424 --> 00:01:21.391
it's the last day before Christmas, the last birthday.

00:01:21.992 --> 00:01:35.063
Oh, yes, well, unfortunately I'm not in that camp, but me too I know a lot of people with christmas following on a wednesday and then new year's eve following the following week.

00:01:35.063 --> 00:01:39.400
I know many people have, you know, tried to sneak to get those extended vacations.

00:01:39.400 --> 00:01:45.537
You know, if you take monday off, I know a lot of places are closed on the 24th or some, uh, close early.

00:01:45.537 --> 00:01:50.254
So everyone's trying to get those breaks in, or that two week break, excellent, excellent.

00:01:50.254 --> 00:01:51.519
How about yourself?

00:01:51.519 --> 00:01:54.968
Are you doing anything interesting for the holiday season besides working?

00:01:54.968 --> 00:01:56.871
Besides working?

00:01:57.033 --> 00:02:12.367
No, I plan to do some side project stuff and having some time with my family over Christmas that's good, that's important the family.

00:02:12.408 --> 00:02:13.689
Time is important.

00:02:13.689 --> 00:02:14.639
Time in general is important.

00:02:14.639 --> 00:02:26.930
I always say and I've been big on this for a long time and anyone who knows me closely understands how I feel about time where you spend your time is what's important and where it should be important, because you don't get any time back.

00:02:26.930 --> 00:02:36.467
Any minute that you spend doing something is a minute that you spent doing something else, and you, you, you know you can't replenish the time that you have in life, so it's important to spend doing this stuff.

00:02:36.467 --> 00:02:38.181
And everybody says do what you enjoy.

00:02:38.181 --> 00:02:39.405
Sometimes I enjoy working.

00:02:39.405 --> 00:02:45.568
Right, it sounds crazy, but sometimes I'm working on something you know from the development point of view.

00:02:45.781 --> 00:02:47.400
It depends what kind of work you're talking about.

00:02:47.661 --> 00:02:49.187
Yes, and people say, oh, you're working so much.

00:02:49.187 --> 00:02:53.050
I'm like well, I enjoy it because I'm fulfilled doing what I do.

00:02:53.050 --> 00:02:57.500
I'm fortunate that I'm one that enjoys what I do on a daily basis.

00:02:57.520 --> 00:02:58.625
Well, that's your purpose, right?

00:02:58.625 --> 00:03:01.468
Sometimes purpose brings that.

00:03:01.520 --> 00:03:03.764
So is that really?

00:03:03.764 --> 00:03:08.954
You know it factors into time anyway, but I hope you have a relaxing holiday season.

00:03:08.954 --> 00:03:10.623
It's and also welcome back.

00:03:10.623 --> 00:03:12.068
It's been a while since we spoke to you.

00:03:12.288 --> 00:03:12.931
Absolutely yeah.

00:03:14.001 --> 00:03:22.532
You know, last time we spoke to you about some neat things, you had a cool app source app that's no longer there because, I think you know they've added it to the AL language.

00:03:23.699 --> 00:03:24.222
VS Code app.

00:03:24.222 --> 00:03:24.764
Yeah, yeah.

00:03:25.145 --> 00:03:27.010
Yes, vs Code app Excuse me not app.

00:03:27.010 --> 00:03:28.485
Jeez, it's Friday.

00:03:28.485 --> 00:03:30.889
So just right now, just forget.

00:03:30.889 --> 00:03:32.758
This is why we don't do Fridays.

00:03:32.819 --> 00:03:37.890
We keep saying not to do Fridays, but Fridays sometimes kind of creeps into our schedule.

00:03:39.281 --> 00:03:50.467
I think, because I say we're not doing Fridays, we're starting to have more and more things scheduled on Fridays because I have a couple recorded calls today, on Friday, so we'll see how that goes.

00:03:50.467 --> 00:04:08.054
Yes, but yes, you had an interesting VS Code app and I saw recently that you introduced a new one for VS Code and that opened up a whole can of I don't want to say can of worms, but a whole can of questions for me.

00:04:08.054 --> 00:04:13.431
But before we get into that, would you mind telling everyone a little bit about yourself?

00:04:13.752 --> 00:04:16.526
Yeah, sure, yeah, my name is Christoph.

00:04:16.526 --> 00:04:19.509
I'm founder of 365 Business Development.

00:04:19.509 --> 00:04:35.413
We are a small ISV in Germany and we are focusing purely on Business Central and developing small apps with the only idea in mind to simplify work in BC.

00:04:35.413 --> 00:04:47.939
So we are not creating some huge extensions, apps, whatever you call it, with a new I don't know contract management functionality or whatever.

00:04:49.021 --> 00:04:52.026
Oh, he had to go there.

00:04:52.026 --> 00:05:09.947
Instead we are, we are just identifying pain points, uh, things which which are not perfect from our point of view, and try to fill them and try to make it easier for for BC customers all over the world.

00:05:09.947 --> 00:05:28.447
And, yeah, and that's why we are pretty much working with AL and BC, of course, and that's why I step into a lot of things, like, like last time we spoke, we see XML documentation stuff.

00:05:28.447 --> 00:05:38.110
So I thought about how we can expose our functionality to our partners, to customers, to make them understand how they can adopt and how they can use it.

00:05:38.110 --> 00:05:57.608
So XML documentation stuff is is created because I think we need something like this, and Microsoft came up, and now the next one comes around the corner and I think it could be pretty cool for the community, and that's why I started my next side project.

00:05:59.363 --> 00:06:00.127
No, I like that.

00:06:00.740 --> 00:06:07.833
And to go back to what you're talking about, the apps and that's something that I've said with a lot of things, that it doesn't always need to be complicated.

00:06:07.833 --> 00:06:19.952
Sometimes to be successful, you just need to handle some of the basics.

00:06:19.952 --> 00:06:24.879
Process is sometimes a little better than creating this whole big thinking.

00:06:24.879 --> 00:06:32.600
We need a big, robust system or, you know, complete module, as you would, within the application to do, you know some fancy things.

00:06:32.600 --> 00:06:40.725
So I appreciate, uh, the apps that you're developing, putting out there in app stores to make the use of business central easier or different.

00:06:40.805 --> 00:06:51.209
I'm not sure that I would agree with easy apps, but but small one absolutely yeah, because, uh, because some, some things were really challenging.

00:06:51.209 --> 00:07:17.848
I I remember in back in 2022 I think, I had a, I had a recording with steve about address validation and we dived in into this little bit and this is also a pretty small app, but into this little bit and this is also a pretty small app, but it's in background it was really tough to implement this and also with direct printing and all this stuff we created.

00:07:17.848 --> 00:07:28.927
On the surface it's just one, two pages and seamlessly integrated into BC, but in the background it's much more.

00:07:28.927 --> 00:07:32.987
Of course, it's like an iceberg, exactly.

00:07:33.922 --> 00:07:51.913
Well, I agree, small to me and for clarification, go back to easy for me does mean the smaller apps, and I'm not saying it takes away from the complexity of what it takes to develop an app, but easy for a customer to use to handle a small, specific function is what I shoot for with those smaller apps.

00:07:51.913 --> 00:07:58.410
So they're smaller, compartmentalized tasks in a sense, or they do specific functions and they do those functions very well.

00:07:58.410 --> 00:08:02.146
See, that's what I've always been told Do what you know and do it well, right.

00:08:02.146 --> 00:08:04.009
So you can't do everything.

00:08:04.009 --> 00:08:10.757
So you have a new app within the visual studio, not app source, but within the visual studio marketplace.

00:08:10.757 --> 00:08:14.826
I get confused and I think it's an interesting app.

00:08:14.826 --> 00:08:18.413
What is that application that you released recently?

00:08:18.434 --> 00:09:20.597
um, yeah, first of all, it's it's not I think it's not just about the app, and the app is relying on a lot of work from other people, like Freddie, like Camille, which did a great job, and basically it's all about adopting NuGet to Business Central and a lot of people, I think inc business, still don't know what's what's new get is and basically it's kind of a distribution feed for for packages, for app files, basically um or artifacts and and um with this, with the introduction, introduction of NuGet into BC, which came from, as I said, freddie and Camille, I think in 2023, they brought a whole new level of complexity into our development, but also a lot of opportunities.

00:09:20.597 --> 00:09:28.921
Opportunities and we could use it.

00:09:28.921 --> 00:09:33.390
I think it was in in summer of 2023 and on bc tech days in antwerp, where, where freddy and camille presented this and we could use it.

00:09:33.390 --> 00:09:38.407
From from this point on it, it was great, but actually nobody does.

00:09:38.407 --> 00:09:48.166
Nobody worked with it, because a lot of people don't really understand why should I use it, what's the benefit and how do I use it.

00:09:48.726 --> 00:10:18.254
And, yeah, maybe we have a little time to talk about it and that's exactly why you're here, because when I hear a NuGet and I know NuGet has been around and you talked a little bit about it's a distribution system I'd like to talk a little bit deeply, a little more deeper about that, how it works, what it does and, even more so, how we can use it within our business central development process, our development workflow.

00:10:18.254 --> 00:10:20.005
I know NuGet's been around.

00:10:20.005 --> 00:10:24.312
I've heard about it with other application languages and it's been around for quite a period of time.

00:10:24.312 --> 00:10:29.763
And you know, sometimes I hear a NuGet, I think of like the stuff within a candy bar, right, I think of like what do they call that?

00:10:29.763 --> 00:10:35.663
Is that NuGet, nugget, whatever they call that stuff that fills some of those chewy candy bars, but with that?

00:10:35.663 --> 00:10:37.188
So let's just take it back a step.

00:10:38.120 --> 00:10:41.171
So NuGet is a distribution system for packages.

00:10:41.171 --> 00:10:42.682
Can we talk about that a little bit deeper?

00:10:42.682 --> 00:10:44.144
System for packages, can we talk about that a little bit deeper?

00:10:44.144 --> 00:10:45.306
Like, how does it work?

00:10:45.306 --> 00:10:47.549
You know we have this distribution system.

00:10:47.549 --> 00:10:48.812
How does it get the information?

00:10:48.812 --> 00:10:50.394
How does it work?

00:10:50.394 --> 00:11:00.032
And then, even more so, if we could progress into how your application works or the extension that you wrote for Visual Studio can be applied to a business central app.

00:11:00.032 --> 00:11:03.547
There's a lot in that conversation right there, so I hope you have time.

00:11:03.886 --> 00:11:06.679
I have I have time, of course Well.

00:11:06.679 --> 00:11:22.335
So Nougat is basically a standardized format on how to distribute artifacts, to be as common as possible, to distribute artifacts for multiple platforms.

00:11:22.335 --> 00:11:31.159
So it's very, very popular in C-sharp or NET, but it's basically not focusing on one specific language.

00:11:31.159 --> 00:11:36.452
And what NuGet basically is is a server.

00:11:36.452 --> 00:11:38.746
You can host it yourself.

00:11:38.746 --> 00:11:46.288
You can use Azure DevOps, for example, azure DevOps feeds, which are also capable to serve as a NuGet server.

00:11:46.288 --> 00:11:53.980
Or, of course, you can use NuGetorg to publish and distribute your packages.

00:11:54.480 --> 00:12:03.027
And what you are basically publishing is not just a pure app file and I don't know, for example, a manifest or something like this.

00:12:03.027 --> 00:12:05.089
I don't know, for example, a manifest or something like this.

00:12:05.089 --> 00:12:12.575
It's a special package which is called NuGet package N-U-P-K-G.

00:12:12.575 --> 00:12:29.772
Basically is a file suffix and inside of this package there's a package manifest which says okay, who's the publisher, what's the identifier of this package, what's the name, what's, what are the available versions?

00:12:29.772 --> 00:12:36.975
Uh, or which one, which is the available version right now, which dependencies you have and and all this stuff.

00:12:36.975 --> 00:12:39.863
And this is all pretty common in in bc world as well.

00:12:39.863 --> 00:12:50.687
So it was pretty natural to to adapt to this instead of we invent the wheel and what this basically brings to our table.

00:12:50.687 --> 00:12:54.734
I think it's not that important to understand what NuGet packages are.

00:12:54.734 --> 00:13:10.144
That's why there are people like Freddie, like Camille and hopefully me, to serve the community and provide tools you just have to use.

00:13:10.144 --> 00:13:16.620
But you don't really need to understand what's technical inside of a NuGet package.

00:13:16.620 --> 00:13:33.057
There are already cmdlets in bc-container-helper to create NuGet packages to use the preferred naming which Freddy and Camille and some other invented.

00:13:33.559 --> 00:13:39.110
Let's say it's this way because in this case we are a little special, because we have a publisher name.

00:13:39.110 --> 00:13:42.148
This publisher name can change over the versions.

00:13:42.148 --> 00:13:44.186
We have an app name.

00:13:44.186 --> 00:13:45.553
This app name can change it versions.

00:13:45.553 --> 00:13:45.768
We have an, an app name.

00:13:45.768 --> 00:13:46.123
This app name can change.

00:13:46.123 --> 00:13:47.504
It's not a breaking breaking change.

00:13:47.504 --> 00:14:01.320
The only thing which needs to to stay forever is the app id basically, and um, the app id is just a good, so it's not very friendly to search for an app id or something like this.

00:14:01.320 --> 00:14:04.205
So they had to thought about, okay, how we name packages.

00:14:04.205 --> 00:14:11.538
So even people and software can find the packages.

00:14:11.679 --> 00:14:19.485
And the big question is basically, what can you do with NuGet packages and what brings NuGet to the table for BC development?

00:14:19.485 --> 00:14:30.173
And I think what's really important to understand is what type of artifacts do we have in BC?

00:14:30.173 --> 00:14:36.448
And basically we have three types.

00:14:36.448 --> 00:14:39.394
We have the classic app file with source code included.

00:14:39.394 --> 00:14:57.264
We have runtime packages which are pre-compiled for a specific PC version and also a localization, and we have symbols and of course we all produce.

00:14:57.325 --> 00:15:06.212
If we work in VS Code and we click package, it compiles a regular app file with all the source code included, the source code, this app file is sent to the server.

00:15:06.212 --> 00:15:13.427
The server recompiles it and uh, or compiles it into into c sharp and runs this on the on the gc server.

00:15:13.427 --> 00:15:20.326
Great runtime packages, as I said, are pre-compiled, so you don't have to do this, this compilation process again.

00:15:20.326 --> 00:15:22.971
But symbols are only references.

00:15:22.971 --> 00:15:40.621
So symbols are basically if you extract the, the app file, it's basically just a huge json file which has all the references all over your application and and so on, and so by references, you're talking about references to the methods to the object the properties to the variables.

00:15:40.721 --> 00:15:43.947
Yes, so you can see the structure without seeing the code.

00:15:43.947 --> 00:15:57.861
You can see the structure of an app versus seeing the the detail of it, so that you could communicate with it, to use the events, the methods and like, without having access to the code or needing access to exactly and and basically the symbols.

00:15:58.222 --> 00:16:05.193
We all know the command download symbols, but basically download symbols is not always true.

00:16:05.193 --> 00:16:19.375
So, as far as I know, if you download symbols from your own BC container, for example, and you have published the app with all the source code, you get the app file with all the source code.

00:16:19.375 --> 00:16:36.288
So it's not just the symbols, but basically the symbols are just a JSON file, a huge JSON file, and basically this is all you need to develop in VS Code and this is all you need to compile your app with a dependency to another app.

00:16:36.288 --> 00:16:48.735
The only thing you need is the symbols, and this is a pretty interesting thing for ISVs and also for Microsoft itself.

00:16:48.735 --> 00:16:52.508
So let's start from another point.

00:16:52.508 --> 00:16:57.052
When we start to develop a VS Code app, what do we need?

00:16:57.052 --> 00:17:09.249
We need some kind of an BC instance right now, because we need to get the system application, we need to get the business foundation base application.

00:17:09.249 --> 00:17:12.748
All this stuff, all these we need the symbols basically.

00:17:13.279 --> 00:17:27.154
And every time you have to restore a certain container or create a certain container in a certain version and maybe in a certain localization, and then you download symbols and you try to start coding.

00:17:27.154 --> 00:17:44.410
And if you want to switch to I don't know another version let's say you support more than just one version you need to throw away your container, create an I don't know BC24 container and do all this stuff again and again and again and again.

00:17:44.410 --> 00:17:48.663
Container and do all this stuff again and again, and again and again.

00:17:48.663 --> 00:17:59.452
And I think I don't know how fast your computers are we are working with, but I think you have to at least wait five minutes, I would say, for a new container.

00:17:59.452 --> 00:18:00.715
Yes, so so what?

00:18:00.715 --> 00:18:01.739
Yeah, so what you're?

00:18:01.798 --> 00:18:18.834
referencing there, just to bring it back, is if we need to build an application for a different runtime or a different version of Business Central, we would need to create a container with that version, publish our extension or download the symbols for that version of the container.

00:18:18.834 --> 00:18:19.674
See Friday, here we go.

00:18:19.674 --> 00:18:21.740
So we download the symbols for that version.

00:18:21.740 --> 00:18:31.352
We would then package our application built with the symbols for the specific version, publish them to our container, use the container helper command to get runtime packages.

00:18:31.920 --> 00:18:40.440
Yes, it does take a few minutes because you would have to, even with scripting all of that, because you can't script that whole process, but it does take time Processing time downloading.

00:18:40.440 --> 00:18:43.586
Yes, and creating the.

00:18:43.586 --> 00:18:46.933
You know it downloads the artifacts to create the container.

00:18:46.933 --> 00:18:52.776
Then now you have to download your symbols, build your application, publish your application, get the runtime package.

00:18:52.796 --> 00:19:00.964
I think it might take a little more than five minutes, and you do that every single time right, it might take a little more than five minutes and let's be honest, at least from my side.

00:19:00.964 --> 00:19:04.012
I know I'm a lazy person, definitely.

00:19:06.319 --> 00:19:25.125
And I have these containers which are three months old, four months old maybe, so it's not the latest version which I develop against, and I don't want to create it over and over again, and it takes just too much time for me.

00:19:25.125 --> 00:19:59.839
And so I thought about, with the presentation from Freddy and Camille, what maybe we can do with all this NuGet stuff to make this faster and to give me the opportunity to say okay, now I want to work against bc24, next I want to use bc24.2 or 25.2 or whatever, and I just want to select it, hit one command and start working.

00:19:59.839 --> 00:20:02.846
That was the basic idea.

00:20:02.846 --> 00:20:05.252
I don't want to create a container over and over again.

00:20:05.252 --> 00:20:16.672
To be honest, last year I started to work with Mac a little more, so I had actually the problem I can't restore a container to develop when I'm not in the office.

00:20:17.381 --> 00:20:18.023
Smart choice.

00:20:18.023 --> 00:20:20.420
By the way, that was a very smart choice to move to Mac.

00:20:20.420 --> 00:20:26.351
I'm not sure, but oh, we might have to end the conversation early.

00:20:29.260 --> 00:20:29.804
You'll get there.

00:20:29.804 --> 00:20:31.390
Maybe I need some more time.

00:20:31.390 --> 00:20:38.207
Yeah, however, the container stuff was really a problem for me and I thought, okay, how can I solve this?

00:20:38.207 --> 00:20:48.289
And the first idea which was a pretty bad idea was to just commit the AL packages folder into my repository.

00:20:50.073 --> 00:20:50.773
Ah, bad idea.

00:20:51.315 --> 00:20:52.877
Cringe Really bad idea, I just cringed.

00:20:53.280 --> 00:20:58.660
I just cringed when I heard that, because talk about wasted space.

00:20:58.660 --> 00:21:05.971
I even share my AL package folder across projects and workspaces because I only need a.

00:21:05.971 --> 00:21:12.211
You know, I found one time on a computer where someone had the al packages for each project, never mind the workspace.

00:21:12.211 --> 00:21:12.861
Right, you can.

00:21:12.861 --> 00:21:14.628
You know the workspace has the setting.

00:21:14.628 --> 00:21:18.040
You can use the al packages and then individual projects.

00:21:18.040 --> 00:21:25.467
I think they saved after they got rid of all of the al packages and I showed them how you can specify the folder and share it, they saved.

00:21:25.467 --> 00:21:28.353
I think it was like 17 gig or something.

00:21:28.413 --> 00:21:39.406
Like it was an absurd amount of space that they were using just with AL packages which, to Chris's point, I call them throwaway because you need to download them for the version that you're working with.

00:21:39.406 --> 00:21:47.792
So if you're doing 25, then 25.1, 25.2, you start building all of those and then you multiply that times all the individual projects that you may be working on.

00:21:47.792 --> 00:21:49.425
It's a lot of space.

00:21:50.500 --> 00:21:52.568
But, as I said, I was in the problem.

00:21:52.568 --> 00:21:55.209
I had a Mac container that doesn't work.

00:21:56.401 --> 00:21:59.167
Oh, the Mac is not the problem with having to check in the same place.

00:21:59.167 --> 00:22:00.731
Yeah, I know, don't try to blame the Mac.

00:22:00.731 --> 00:22:09.750
No, no, no, no, no, but, no, no, no, no, no, no, but it was my starting point.

00:22:09.790 --> 00:22:10.915
So it's just the start of a journey.

00:22:10.915 --> 00:22:13.586
Yeah, and, as I said, I recognized very, very fast that's not a good idea to do.

00:22:13.586 --> 00:22:47.440
So I decided to dive into this a little bit and, really fast, came up with some PowerShell scripts and invoked nougat directly and created nougat packages, uh configurations to to download the packages I needed, and it took some, took some time, but at some point I said, okay, maybe, maybe it's worse to to invest a little more time into this and uh, integrate this right into vs code.

00:22:47.440 --> 00:22:51.150
And then I thought about okay, how you can do this?

00:22:51.150 --> 00:23:04.076
And of course, I I look to the, to the big brother visual studio, um, because there it's, it's already already there for I don't know how many years, and it works.

00:23:04.076 --> 00:23:05.700
It's intuitive.

00:23:06.903 --> 00:23:15.105
So why not keep this as a template and try to do this in VS Code as well?

00:23:15.105 --> 00:23:27.049
And right before directions in here, to be honest, because I promised this on Twitter, so that's why I was a little in a hurry.

00:23:27.049 --> 00:23:46.490
I just published the first two or three preview versions, which are already working but are far away from perfect and far away from, I would say, usable for productive uh development.

00:23:46.490 --> 00:23:56.669
But, um, the most important thing for me is that it's not just about about local vs code development.

00:23:56.669 --> 00:24:28.529
When we start adopting to nuget and and and creating all the artifacts the nugGet artifacts like the package config I told about and put this into our repo, we got a whole new dimension in DevOps or GitHub as well, so in our pipelines we can also restore packages directly from NuGet feeds and compile against them, and it's super, super fast.

00:24:30.981 --> 00:24:49.124
So where that's helpful then would be if you're working on an extension within AL an AL extension for VS Code and you want to put it into a pipeline, you no longer have to get you know if you have a dependency of another extension.

00:24:49.124 --> 00:24:53.093
It could be from an ISV it could be from Microsoft.

00:24:54.541 --> 00:25:00.048
At least two extensions are always in place it's a system app and application itself.

00:25:00.779 --> 00:25:08.627
So at least two dependencies so that way you can build based on it for a specific version or even just the latest version.

00:25:08.627 --> 00:25:16.067
So by putting in the NuGet path right to download the AE which we can talk about how that works in a moment.

00:25:16.067 --> 00:25:20.288
So when you're going to build, you basically put a reference for the dependency.

00:25:20.288 --> 00:25:36.711
It will download the symbols from the NuGet server, whichever one you're using, that you had mentioned, and use those artifacts for you to package and build your extension without having to download the symbols yourself.

00:25:37.260 --> 00:25:45.788
And create a container and as long as you don't want to execute tests in, execute uh tests in it.

00:25:45.788 --> 00:25:51.015
It's, it's fine and uh, what I?

00:25:51.015 --> 00:25:59.232
What I tried as a some prototype it's not, it's not ready yet for cicd purposes is back in the days.

00:25:59.232 --> 00:26:03.686
We now have, I think, seven or eight apps and back in the days, uh.

00:26:03.686 --> 00:26:15.383
Well, right now, also, as a productive, we run each and every night, each and every uh app against current, next minor, next major, and run our tests and do all these.

00:26:15.383 --> 00:26:20.632
And right now it's still working with our time frame in the night.

00:26:20.632 --> 00:26:28.503
But at some point, if we, if we uh releasing new apps and new apps and new apps, it will not fit into the night anymore.

00:26:29.526 --> 00:26:38.130
So what my idea currently is is, of course, I want to run my tests, but the whole process of compilation and and creating a container.

00:26:38.191 --> 00:26:40.542
I don't need to use this for each and every app.

00:26:40.984 --> 00:26:52.954
So what I dream about is I have one pipeline which is just creating the artifacts by downloading symbols, packaging, push this to our own NuGet feed.

00:26:52.954 --> 00:27:11.228
And there's another pipeline which is just downloading one artifact after one app after another, publishes, executes tests after another, publishes, executes tests, remove it or let it there whatever you want and do this again, and again, and again.

00:27:11.228 --> 00:27:21.663
So you'd only need one container and because of the isolation in tests, you don't have any side effects if you run multiple tests in in with separate uh well, with different apps.

00:27:21.663 --> 00:27:44.750
So this is what I think we can save a lot of time and also can have the possibility to see side effects between the apps If we disable the isolation, for example, what you can do in tests, then you can see okay, it's my app one somehow influencing my app.

00:27:44.750 --> 00:27:58.299
Two, because you do this all in one environment and you do this much, much faster than previously, because you don't need to create a container.

00:27:58.299 --> 00:28:04.757
I don't know, eight times in my situation or eight times.

00:28:04.797 --> 00:28:13.881
Three, basically because you're doing the current the next minor, the next major, so you're doing three builds in essence for each.

00:28:13.881 --> 00:28:35.261
So with this so even take it, so you're doing it internally you have eight application extensions that you have for Business Central and with those eight applications you publish them to NuGet, you push them to NuGet and then you can keep multiple versions of those in there.

00:28:35.261 --> 00:28:36.769
And is that the intent?

00:28:36.769 --> 00:28:47.619
So that if you have version 24.1.9000, 24.1.10000, do you keep all of them in there, or is it just for each build of business central?

00:28:48.142 --> 00:28:52.974
um, you know, basically, basically, we have, we have, we are.

00:28:52.974 --> 00:28:58.065
We are very focused on just having one code base for all the bc versions we are.

00:28:58.065 --> 00:29:00.369
We are supporting we're not just supporting cloud which this for all the BC versions we are supporting.

00:29:00.369 --> 00:29:03.436
We're not just supporting cloud, this would be way too easy.

00:29:03.436 --> 00:29:12.584
We're also supporting on-prem and so typically we are supporting from BC 18 to the latest version.

00:29:12.584 --> 00:29:22.491
So what we do to master this is we are working a lot with preprocessor symbols, so compiler directives and say if bc.

00:29:22.633 --> 00:29:24.215
By the way, blah, blah, blah.

00:29:24.757 --> 00:29:30.194
So, and this is working pretty pretty well, but it's it limits us, of course.

00:29:30.194 --> 00:29:39.458
For example, if you want to use namespaces in our, in our apps, um, we need a lot of this hashtag.

00:29:39.458 --> 00:30:09.318
If BC blah, blah, blah stuff, and this is not very readable, but as as long as we, as we stick to the on-prem customers and say, okay, we want to just serve one code base, um, I think we we need to do this and um, yeah, but, but nevertheless, we store all our packages, at least the latest version of each minor version we created.

00:30:09.318 --> 00:30:12.897
We store them forever.

00:30:12.897 --> 00:30:14.875
Why, to be honest, I don't know why.

00:30:14.875 --> 00:30:18.339
I decided this sometime and never thought about it again.

00:30:20.051 --> 00:30:24.056
But, yeah, you see all the packages in NuGet and you can reference to it.

00:30:24.056 --> 00:30:37.009
And if you, for example, having multiple code bases for the different BC versions, of course you can do this with what Freddy called or what NuGet called it, indirect packages.

00:30:37.009 --> 00:30:48.858
So you have basically one package which is empty but which references to another package or another package per version, and this package has a different naming and so on.

00:30:48.858 --> 00:30:55.390
But that's not relevant, but it's more like a sitemap from a website.

00:30:55.390 --> 00:30:59.758
So you come there and you say, okay, I'm looking for 21 point whatever.

00:30:59.758 --> 00:31:01.691
And it say, okay, go this.

00:31:01.691 --> 00:31:03.295
Say okay, I'm looking for 21 point whatever.

00:31:03.295 --> 00:31:04.557
And it say, okay, go this way.

00:31:04.557 --> 00:31:05.540
I'm looking for 25 point one.

00:31:05.540 --> 00:31:06.182
Okay, go this way.

00:31:06.924 --> 00:31:31.660
That's basically all all the magic behind an indirect package so an indirect package allows you to have multiple versions and that would be useful for those application extensions that if somebody's working with an on-premises install where they have a specific version, oftentimes you would call the ISV and say I need runtime version 18, you know a runtime version for 18.4.

00:31:31.660 --> 00:31:32.761
Can you send it to me?

00:31:32.761 --> 00:31:49.402
Yeah right, so doing it this way, where it'd be helpful to an application publisher when I say application publisher, anybody that has an app that would be helpful to an application publisher, when I say application publisher, anybody that has an app that would be used as a dependency potentially you can get it from NuGet.

00:31:49.402 --> 00:31:52.901
In that case, would it be the entire runtime version or just the symbols?

00:31:56.053 --> 00:31:57.769
That's up to the publisher basically.

00:31:57.769 --> 00:32:14.021
So what we are doing and some other ISVs I know about, they are shipping runtime packages, complete runtime packages with the pre-compiled source code for the specific localization and PC version in NuGet feeds.

00:32:14.021 --> 00:32:26.855
But I also know one publisher which just chips symbols over the NuGet feeds, but that's also fine.

00:32:27.778 --> 00:32:30.338
Okay, it's up to the ISV how they like to distribute it.

00:32:30.338 --> 00:32:42.025
But where it becomes helpful from an app publisher is they can publish the information for the specific versions, including the latest version, to make it easier for everybody to have a dependency.

00:32:42.025 --> 00:32:45.578
Based upon that, I want to get into your app because this sounds like a lot.

00:32:45.578 --> 00:32:47.577
I understand the process now of what it does.

00:32:47.577 --> 00:32:58.393
I have a good sense of how it could be applicable to me, I think in my daily development One thing that I was thinking of when you asked this question, when you were talking about this process.

00:32:58.393 --> 00:33:04.903
So how does it know the validity of the package?

00:33:04.903 --> 00:33:12.320
It may or may not be such a case with you know some business central development or not, depending upon what the application does.

00:33:12.320 --> 00:33:27.549
But how do I, how can it be prevented that I don't publish an application saying that I'm the Microsoft system application or Chris's application development company?

00:33:27.549 --> 00:33:36.525
How do I know that the validity of what's in that NuGet package is from the publisher that says it is and it's a trusted publisher?

00:33:38.393 --> 00:33:40.799
Yeah, that's a problem.

00:33:40.799 --> 00:34:09.860
Basically there are public NuGet feeds like NuGetorg and you as a publisher can go to NuGetorg and say, okay, I reserve the prefix Microsoft dot for my apps and only I can publish apps with this prefix and, um, that's kind of kind of a security mechanism.

00:34:09.860 --> 00:34:28.021
But when I reference to what, what, what freddy said in in in bc tech days and I also see I think Camille said on Directions EMEA this year, don't trust NuGetorg because you don't know what's inside there.

00:34:28.021 --> 00:34:29.235
It could be anything.

00:34:29.235 --> 00:34:37.061
But all the Microsoft itself has three NuGet feeds right now.

00:34:37.061 --> 00:34:42.295
One is for Microsoft symbols, one is for Microsoft apps and one is for AppSource symbols.

00:34:42.295 --> 00:34:48.057
So each and every AppSource app is already published by Microsoft in the latest version.

00:34:48.057 --> 00:34:56.835
So there's a NuGet feed available where you can search for each and every AppSource app and put a reference on it and use it.

00:34:58.079 --> 00:34:58.961
So Microsoft?

00:34:58.961 --> 00:35:01.773
So they have a server themselves for their symbols.

00:35:01.773 --> 00:35:02.938
It's basically DevOps.

00:35:03.190 --> 00:35:10.494
It's a DevOps instance, Azure DevOps instance, and they are serving us a public NuGet feed from well.

00:35:10.494 --> 00:35:12.657
Three public NuGet feeds, basically, from there.

00:35:14.090 --> 00:35:15.719
Including all the apps in AppSource.

00:35:15.719 --> 00:35:18.750
For the latest version of the app that's in AppSource.

00:35:18.949 --> 00:35:29.695
Absolutely, and at this point, when you submit a new app in Marketplace, it will be automatically populated to the NuGet feeds as well, so you don't have to care.

00:35:29.695 --> 00:35:33.059
As an AppSource publisher, you don't have to care about all this stuff.

00:35:35.570 --> 00:35:37.797
That's pretty cool.

00:35:37.978 --> 00:35:46.235
It is definitely Now I'm anxious to know how I use all of this and, additionally, a lot of ISVs.

00:35:46.235 --> 00:35:53.960
To be honest, currently it's a little wide west, so there are naming conventions.

00:35:53.960 --> 00:35:56.389
It's pretty much the same, like the early days in AL.

00:35:56.389 --> 00:36:22.282
Like the early days in AL, we started with codnumbernameal and then we changed this all and now it's the object namecodeunital, and I see a lot of people which are using some completely different naming conventions and deactivate the code cops for complaining about this stuff.

00:36:22.282 --> 00:36:25.478
And in NuGet it's pretty much the same.

00:36:25.478 --> 00:36:39.936
We have AL now in place I think from 2018, I think and the possibility was always there to do things like NuGet, but no one did.

00:36:40.277 --> 00:36:48.545
And, as I said last year at Tech Days, I heard more or less the first time from this topic.

00:36:48.545 --> 00:36:53.516
So it's five years later.

00:36:53.516 --> 00:37:20.842
And, of course, isvs like we are had the problem to you referenced that you go to a publisher and say, hey, I need a runtime package for version 18, 20, whatever, and then the most of them say, okay, I need a day and then I will serve it to you, and some other ISVs came up with the idea and said, no, I don't want to do this.

00:37:20.842 --> 00:37:35.277
I ship my packages as runtime packages, precompiled, and you can download this just from my website or from a universal package feed or from whatever you want to use, and we, for example, we have just a download page.

00:37:35.277 --> 00:37:38.838
Go there, there's your apps, select your version, click download.

00:37:39.661 --> 00:37:42.931
Happy, but this is the old one.

00:37:42.931 --> 00:37:45.878
Uh, when we started to adapt to to new get, we will.

00:37:45.878 --> 00:37:51.356
We will deprecate the site and completely switch to new get because it's much easier to maintain for us.

00:37:51.356 --> 00:37:56.233
But, um, we all the publishers, had the problem.

00:37:56.233 --> 00:38:06.282
Okay, how do we serve customers, other partners, with our packages in certain versions which are not in Epsos?

00:38:06.282 --> 00:38:15.639
And they all invented clever solutions, but it is how it is.

00:38:15.639 --> 00:38:24.144
When you ask 10 people, you got 13 answers how you can do things.

00:38:26.112 --> 00:38:27.277
And that's how it is currently.

00:38:27.590 --> 00:38:33.123
So naming conventions from the packages is pretty important for software.

00:38:33.123 --> 00:38:38.918
We have a manifest and, in best case scenario, we have an app ID.

00:38:38.918 --> 00:38:41.402
We have the publisher name and we have the app name.

00:38:41.402 --> 00:38:46.521
As I said, publisher name and app name are fluent.

00:38:46.521 --> 00:38:47.996
They can change over the time.

00:38:47.996 --> 00:39:06.139
So the only thing which you can rely on is the app ID and you specify a minimum version you support, which is also quite complicated because, let's be honest, how often do you update the version number in your dependencies?

00:39:09.550 --> 00:39:14.835
Yeah, right Depends it depends.

00:39:14.835 --> 00:39:25.083
I personally would go and update it because if I have a dependency on an app that adds a new method or adds something new, I'll go in and change it on the app that uses that dependency.

00:39:25.083 --> 00:39:35.117
And I will say, yesterday I was running some tests and I looked at the app file because I had to update the app file version of the tests and they were all version 20.

00:39:35.117 --> 00:39:36.755
And this was for version 25.

00:39:36.755 --> 00:39:38.536
So I updated the version 25.

00:39:38.998 --> 00:39:40.639
Yeah, it's the same with me.

00:39:40.639 --> 00:39:45.342
I'm lazy, as I said, and, um, yeah, then you have to.

00:39:45.342 --> 00:39:48.452
You have to think okay, how can the software determine which version is?

00:39:48.452 --> 00:39:50.900
Is what you're looking actually looking for?

00:39:50.900 --> 00:39:56.523
When you just have one container where you specified which version the container is running off?

00:39:56.523 --> 00:40:03.300
It's pretty easy because you just say, hey, I have this app, please give me a version, and you just get the version which is basically there.

00:40:03.300 --> 00:40:29.722
Um, but when you have an artifacts feed where you have all the versions from the beginning to wherever you are today, you have to select the right one, and this is a little complicated, and so we need things like naming conventions, we need things like rules where the partner is working with.

00:40:29.722 --> 00:40:39.802
So some partners I know about are just using the BC numbers so 25.1, 25.2, and then their version is following.

00:40:39.802 --> 00:40:48.221
Some are completely in their own number range, so it's tough for a piece of software.

00:40:49.871 --> 00:40:56.518
So, if I'm an application developer, I want to go from this in both ways, because I understand the concept of how it works.

00:40:56.518 --> 00:41:00.769
One thing we talked about from an ISV point of view you had mentioned.

00:41:00.769 --> 00:41:04.018
Or from ISV point of view you had mentioned, or from a consumer point of view.

00:41:04.018 --> 00:41:05.996
I do want to talk about how to consume this right.

00:41:05.996 --> 00:41:09.442
I understand the process now as far as conceptually how it works.

00:41:09.442 --> 00:41:22.137
You had mentioned not to trust NuGetorg all the time, or to be leery of the extensions and then verify that it's authentic, or someone could host their own.

00:41:22.137 --> 00:41:26.257
If I'd like to host my own, you said I could set it up in DevOps.

00:41:26.257 --> 00:41:28.817
Right, is what you use for an example.

00:41:28.817 --> 00:41:33.400
What if I don't want to host my own?

00:41:33.400 --> 00:41:34.896
Does my only option NuGetorg?

00:41:34.896 --> 00:41:36.556
Does Microsoft have something?

00:41:36.556 --> 00:41:45.994
Are there other places that you could put this where it could be authenticated that it's you that is actually sharing this file there?

00:41:46.016 --> 00:41:47.400
are different providers.

00:41:47.400 --> 00:41:49.856
The most common is basically NuGetorg.

00:41:49.856 --> 00:42:04.797
And if you use the verification stuff and if you keep your stuff together, the secrets together and all this stuff, it's pretty secure that we are working with the right publisher.

00:42:07.833 --> 00:42:11.862
But what you have to keep in mind is the only reference we have is the app ID.

00:42:13.250 --> 00:42:20.969
So when you download using NuGet, basically we are looking for the app ID using NuGet, basically we are looking for the app ID.

00:42:20.969 --> 00:42:32.396
And if someone is not that friendly and uses the same app ID because that's basically possible you can just specify any GUID you want and push this to NuGetorg.

00:42:32.396 --> 00:42:38.032
It doesn't need to prefix with Microsoft, so it's not secured.

00:42:38.032 --> 00:42:46.972
But maybe the software thinks hey, there's the app ID, so this is the right one and I'm looking and I'm downloading this one and this is how.

00:42:46.972 --> 00:43:07.710
So we have to go from one thing which is just the app ID to a whole complex NuGet naming thing which, in Freddy's preference it contains the publisher name, dot.

00:43:07.710 --> 00:43:09.751
The app name, dot.

00:43:09.751 --> 00:43:14.130
Maybe symbols, dot, maybe country code, dot.

00:43:14.130 --> 00:43:15.335
App ID at the last.

00:43:15.335 --> 00:43:21.472
And if you have these components in the name we can make the software.

00:43:21.472 --> 00:43:23.856
For example, my extension, or also NuGet.

00:43:23.856 --> 00:43:30.485
The NuGet executable itself can make pretty sure that you are running against the right publisher.

00:43:30.485 --> 00:43:37.219
But when you're just seeking with the app ID, that's not that much of a problem.

00:43:37.458 --> 00:43:59.094
All the big ISVs have now kind of NuGet feeds in place or universal packages feeds in place, so all the big ones have it and as far as I know, the big ones which do not have a NuGet feed, they're working on it.

00:43:59.094 --> 00:44:04.418
And if we serve more and more tools Freddie did a great job in VC Container Helper.

00:44:04.418 --> 00:44:22.452
Patrick did also a great job with his DevOps extension to, with his DevOps task I think it was a task to download packages and also his NuGet helper extension in VS code.

00:44:22.452 --> 00:44:45.806
So there's another one in place already and so as more tools we have, as more partners as more ISVs will use it, and I think it's the first days I also said okay, of course, we reserved our prefix at NuGetorg, but we never published a single package there because we don't need it.

00:44:45.806 --> 00:44:47.706
We have DevOps and all the others too.

00:44:49.420 --> 00:44:55.110
Okay, so now we have multiple feeds that are available and the authenticity of a NuGet package.

00:44:55.110 --> 00:44:58.907
It's not just an AL thing, that's just the way NuGet works in general.

00:44:58.907 --> 00:44:59.789
So I just wanted to point that out.

00:44:59.789 --> 00:45:15.623
It's something to be aware of and just make sure that you know the source of where you're getting the file and what you're getting with it, so an ISV can publish their extensions I understand the concept of that to their NuGet feed.

00:45:15.885 --> 00:45:27.972
Right Now I want to write an extension that is dependent upon the Microsoft application the Microsoft system application, the base app, the system app and the foundation app.

00:45:27.972 --> 00:45:30.690
So I have those three dependencies right from the beginning.

00:45:30.690 --> 00:45:39.342
Then also, now you have an extension that I, you know, think is a wonderful extension, but maybe I want to make one slight change to the process.

00:45:39.342 --> 00:45:41.228
So I have to use yours as a dependency.

00:45:41.228 --> 00:45:42.621
I'll subscribe to event and do something.

00:45:42.621 --> 00:45:46.429
How do I get it and how do I know where it is?

00:45:46.429 --> 00:45:50.199
And then, how do I get it within my application?

00:45:50.380 --> 00:45:53.847
Because now, as you talked about, I could create a container.

00:45:53.847 --> 00:45:55.853
I get the symbols from you or I.

00:45:55.853 --> 00:45:57.606
You know, I download it into my.

00:45:57.606 --> 00:46:01.943
If it's an online environment, I can install it in the online environment.

00:46:01.943 --> 00:46:06.822
If it's a container, I get the package and install it, download my symbols and that symbol is there.

00:46:06.822 --> 00:46:16.842
In this new case, I'm no longer going to a BC environment whether it be a container-based environment or an online environment to get the symbols.

00:46:16.842 --> 00:46:18.364
I'm going to a NuGet feed.

00:46:18.364 --> 00:46:19.887
How does that work?

00:46:19.887 --> 00:46:22.353
That is where now I'm stuck.

00:46:22.353 --> 00:46:28.393
How do I know to go to this post office box to get the file for this particular version?

00:46:28.393 --> 00:46:30.519
How do I do that as an AL developer?

00:46:30.679 --> 00:46:32.344
Basically, as an AL developer.

00:46:32.344 --> 00:46:33.588
There's no difference.

00:46:33.588 --> 00:46:38.621
The only thing which changes is the command you executed.

00:46:38.621 --> 00:46:42.851
So you're not hitting AL download symbols.

00:46:42.851 --> 00:46:47.081
Instead, you may hit restore Nuget packages.

00:46:47.081 --> 00:46:48.405
And what happens?

00:46:48.405 --> 00:46:51.072
The NuGet package will be downloaded.

00:46:51.072 --> 00:46:59.688
So the package will be identified, it will be downloaded, it will be extracted and the app file from in the package will be placed in the AL packages folder.

00:47:01.722 --> 00:47:03.940
So the only thing I have to do is rebuild NuGet packages.

00:47:03.940 --> 00:47:08.007
Restore yeah, basically, oh, restore, but is that with?

00:47:08.007 --> 00:47:14.275
Okay, I want to talk about your extension soon, but is that within the AL language to restore NuGet packages?

00:47:14.295 --> 00:47:15.260
That's within your extension.

00:47:15.260 --> 00:47:18.755
Yes, what I did, and that's also what Patrick did, was this NuGet helper extension.

00:47:18.980 --> 00:47:21.451
Okay, so now.

00:47:21.451 --> 00:47:26.268
So within your extension, what's the name of the extension that's in the VS Code marketplace, if anybody wants?

00:47:26.288 --> 00:47:26.909
to search for it.

00:47:26.949 --> 00:47:30.561
ALget AL not.

00:47:30.661 --> 00:47:31.764
NuGet.

00:47:31.905 --> 00:47:33.489
ALGET, alget, alget.

00:47:33.489 --> 00:47:39.032
Okay, so with ALGET, I install the extension.

00:47:39.032 --> 00:47:47.750
The ALGET will look at the dependency in my app file and then, based on that dependency, how does it know where to go?

00:47:48.300 --> 00:47:49.221
And then, based on that dependency.

00:47:49.221 --> 00:47:49.882
How does it know where to go?

00:47:49.882 --> 00:47:52.565
So built in or baked into the extension.

00:47:52.565 --> 00:48:02.635
Of course the Microsoft feeds are there, so you don't have to specify the Microsoft feeds, the app source feed, the app symbols and the MS symbols and the MS apps.

00:48:02.635 --> 00:48:17.030
So it's all three in there and by default it looks up to this feeds at first and tries to download the apps from there.

00:48:17.030 --> 00:48:33.206
And if it's not, if it doesn't find the symbols, the artifacts or the nougat packages in there, we will look for custom feeds which you can specify, for we have some custom feeds for our own apps, for our internal stuff and also for partners we are working with.

00:48:33.206 --> 00:48:42.168
And then it looks there and says, okay, maybe I find something, and then it downloads it basically oh, okay.

00:48:42.168 --> 00:48:43.932
So that makes it much easier.

00:48:43.992 --> 00:48:49.072
So in your settings, I'm sorry so in your settings you can specify the additional feeds to work with.

00:48:49.072 --> 00:48:56.771
So, as an AL developer, I install your extension, which already makes it so much easier, because I just have to do, you know, rebuild.

00:48:56.911 --> 00:48:57.532
What do you say Rebuild?

00:48:57.532 --> 00:48:59.313
I always want to say rebuild, restore.

00:48:59.313 --> 00:49:02.447
I knew it wasn't rebuild, so I just recycled it.

00:49:03.940 --> 00:49:06.224
No, no, it's good, it's good, I'll have to get the restore.

00:49:06.224 --> 00:49:09.652
So if I click restore, it works.

00:49:09.652 --> 00:49:10.233
I like that.

00:49:10.233 --> 00:49:18.045
So then if I have a dependency with an ISV or somebody else, I would ask again.

00:49:18.045 --> 00:49:36.085
So what I would need to do is ask them where are your NuGet packages, and if they have them, they would send me the URL right that says here's where my packages are, and then, within your extension, there's a setting where you could list all of those custom ones, and when you go to look for the packages, you go through those custom settings.

00:49:36.085 --> 00:49:37.990
Oh, that makes it so much easier.

00:49:37.990 --> 00:49:39.405
See, now I don't even need to understand this.

00:49:40.260 --> 00:49:43.222
It's like Lego pieces, right, Like it's just like it's.

00:49:43.222 --> 00:49:47.507
It's uh, you, you're building something and it's like yeah, I need something very specific.

00:49:47.507 --> 00:49:56.063
I'm going to look at this, this bucket, or in this, in this case, and you get, if it already exists, perfect, I don't have to build it.

00:49:56.766 --> 00:49:57.286
And what's a?

00:49:57.286 --> 00:49:57.688
What's a?

00:49:57.688 --> 00:49:58.451
Pretty sounds like that.

00:49:59.340 --> 00:50:36.307
Pretty nice thing is at some point we are not there at the moment and maybe not next year, but at some point maybe we got the idea of new get also into the PC world, because everyone who ever works with, with dotnet like like C sharp or something like this, and started with Jason, everyone knows Newton self, that Jason, no one writes his own class to pass json files and it's not from microsoft and everyone used just this as an library.

00:50:37.190 --> 00:51:04.264
And maybe at some point we are not just the community, the dynamics community will not just publish apps, commercial apps, but also apps which are some kind of a library and solving a problem which is not that important that it can be placed into a system application or something like this, but it serves a specific need.

00:51:04.264 --> 00:51:38.690
And maybe we can go to this as well, at least in my fantasy, and say, okay, I don't need to create and let's, let's stick with the json, json example, I don't need to create and pass a parser for json and and I can just use the package from from publisher x, x, y, because I know this one, because the community talked about it or whatever, and I just use this as a reference in my package and I don't have to re-enroll, I like it.

00:51:39.121 --> 00:51:41.146
I think of, like the type helper code unit.

00:51:41.146 --> 00:51:43.947
I think of some of those, what I call those utility libraries.

00:51:43.947 --> 00:51:49.789
A lot of individuals make utility libraries that are available on GitHub that I could download and use and incorporate.

00:51:49.789 --> 00:51:52.168
But in what you're saying I like that idea.

00:51:52.168 --> 00:52:03.335
Now we could have even a community-driven library right that you could call a quote open-source library for AL that people can contribute to.

00:52:03.335 --> 00:52:12.025
Again, if you want to reference the JSON parser that you had mentioned, that we can just continually build upon from the community point of view to help AL developers.

00:52:12.025 --> 00:52:13.481
So I agree with you At that point.

00:52:13.481 --> 00:52:19.260
It's not a marketplace right or an app source gallery.

00:52:19.983 --> 00:52:20.746
It's like Amazon.

00:52:22.103 --> 00:52:23.307
I like what you said with Lego.

00:52:23.307 --> 00:52:25.425
It's pretty much like Lego.

00:52:25.425 --> 00:52:40.726
You don't do all the components over and over again, you just reuse what's already there and if there's an issue and the maintainer or the maintainers found this, they fix it and it can be a community project.

00:52:40.726 --> 00:52:52.800
It can be open sourced, and it's not necessarily it must be necessarily controlled by microsoft, which is not a bad thing at all.

00:52:52.800 --> 00:52:59.440
So it's great, but not everything belongs into a system app no, I agree with you there.

00:52:59.541 --> 00:53:09.661
And then also sometimes you can you get I don't want to say it's better sometimes microsoft has their efforts focused on certain areas of the application.

00:53:09.661 --> 00:53:13.056
It's their application justify that don't fault them right, they don't have.

00:53:13.597 --> 00:53:20.599
Nobody has the resource you know the resources, whether it be dollars or talent to do everything for everybody.

00:53:20.599 --> 00:53:24.130
Right, so they have a timeline for what they're working on with the application.

00:53:24.130 --> 00:53:41.436
But if there was a way to pull in some things where others could create beneficial tools to supplement that you, you know, similar to what they're doing with the contribution pilot, which is great because it allows community members to enhance the functionality of the application in addition to what they have on their plan.

00:53:41.436 --> 00:53:51.413
This would create a list of tools as technology comes out, because anytime there's a new technology, everyone's like well, how do we communicate with web services, for example?

00:53:51.413 --> 00:53:53.916
How can I consume API endpoints within Business Central?

00:53:53.916 --> 00:54:13.375
You know, I know we have the libraries in there now, but if the libraries don't exist, if somebody could create them, use them as a dependency, you know everybody could build it, and in some cases it's better because you have multiple eyes looking at it, versus somebody creating one thing that they're putting in a black box.

00:54:13.375 --> 00:54:15.621
I like that idea, see.

00:54:15.681 --> 00:54:27.925
I think this will open up and I'm still waiting for ALnet by the way, it will need a lot of time because we have one big problem in AL which prevents from doing this right now, and that's basically the object ID.

00:54:27.925 --> 00:54:30.034
Oh, forget, it prevents from doing this right now.

00:54:30.054 --> 00:54:31.016
And that's basically the object ID.

00:54:31.016 --> 00:54:31.760
So, oh, forget it, I'll be.

00:54:31.760 --> 00:54:37.112
I was hopeful that that object ID would go away many years ago.

00:54:37.320 --> 00:54:39.047
I thought they'd been talking about that for a while now.

00:54:39.800 --> 00:54:46.503
You know from what I see and hear and what I read, right, everything you read on the internet is true is.

00:54:46.503 --> 00:54:56.766
You know there's been discussions about the object IDs and I guess a lot of the core foundation architecture and the service tier still uses the id, so they'd have to do an overhaul of that.

00:54:56.766 --> 00:54:59.014
Part of me just wants to say just do it.

00:54:59.014 --> 00:55:01.503
You know we're getting to the point where you know we have.

00:55:01.503 --> 00:55:04.480
You know, naming collisions is something we have to look at.

00:55:04.480 --> 00:55:06.143
We have to look at object id collisions.

00:55:06.143 --> 00:55:07.666
They're still both unique.

00:55:07.666 --> 00:55:12.653
There's like we have now multiple unique identifiers for an object, which is limiting.

00:55:12.653 --> 00:55:16.360
So I would love to get rid of the object id.

00:55:16.360 --> 00:55:25.231
Now I know the challenge is with the object id because you have licensing for on-premises, because you still license the objects that you're going to utilize on the online.

00:55:25.231 --> 00:55:29.925
You don't have that limitation because you still can work between the 50 000000 and 99,000 range.

00:55:30.007 --> 00:55:36.847
But I would love the object IDs to go away on the field level as well as the table level or, excuse me, the object level.

00:55:36.847 --> 00:55:45.869
You know the field level and tables and then also the objects ID for the objects in there, and maybe I won't be around when they finally get rid of it.

00:55:45.869 --> 00:55:48.793
In that time, that's what I would like you know, we should have.

00:55:48.793 --> 00:55:53.251
You know, chris, next year we have to put a note, we need to have.

00:55:53.251 --> 00:55:54.862
What are your 12 wishes for Christmas?

00:55:54.862 --> 00:56:00.862
And I think one of my wishes for Christmas, my number one, would be get rid of the object IDs, because they're just a pain.

00:56:01.264 --> 00:56:06.088
I would say save this wish for the next two years.

00:56:06.088 --> 00:56:07.550
I think that's.

00:56:08.000 --> 00:56:12.847
You think two years maybe two years we see it developing very very fast.

00:56:12.907 --> 00:56:41.942
But I think I think in the base code of all the service stuff and platform there's a lot of stuff with with object IDs and so on, so they have to rethink a lot of things like like record references they all work with with object ids and yes, so I think this is not an easy task to to serve, but of course this is much.

00:56:42.742 --> 00:56:48.994
This is preventing uh from from shipping libraries, because when you develop a library you have to.

00:56:48.994 --> 00:56:53.190
Okay, what object idea did I take for this?

00:56:53.190 --> 00:57:00.764
And how do I make sure that in my customer tenants it's not already taken by PTE or by whatever?

00:57:01.987 --> 00:57:04.652
Whew, it's tough.

00:57:04.652 --> 00:57:06.135
Yes, I see Good luck.

00:57:06.135 --> 00:57:13.028
You'd have to have the app source range, which is the only thing that you could have to limit it, but you still think two years, that's interesting.

00:57:13.028 --> 00:57:13.420
Two years.

00:57:13.420 --> 00:57:15.047
We'll talk and see if it's going.

00:57:15.460 --> 00:57:26.512
I think just look back as I said, I think 2018 BC came really up and all the naming and see what happens in this time.

00:57:26.512 --> 00:57:27.905
We got a lot of things.

00:57:27.905 --> 00:57:29.365
We got a lot of cool things.

00:57:29.365 --> 00:57:39.447
We got interfaces, namespaces we still have prefix and suffix, but at least we have namespaces now.

00:57:39.760 --> 00:57:52.219
I think maybe the namespaces will help speed that along, because now we're getting more and more conventional with the development within al.

00:57:52.219 --> 00:58:03.445
It's almost c-sharp, like, in a sense, right with a, with a hint of pascal, still um, so that that would be my wish list.

00:58:03.445 --> 00:58:11.148
That's what I want santa to bring, but I won't get that this year and I'm hoping that I'll see it in my lifetime.

00:58:12.431 --> 00:58:15.688
Well, in my career, as I said, it's in my wildest dreams.

00:58:15.688 --> 00:58:52.663
Maybe at some point we will be there and we will use packages not just as commercial apps or free apps in App Store's range or free apps in AppSource range, but also as components for our solutions, for our PTEs, for our ISV solutions and not every ISV needs to create a text editor and not every ISV needs to create, I don't know the common, common stuff which comes over and over again no, there are.

00:58:52.704 --> 00:58:53.143
There's some.

00:58:53.143 --> 00:58:56.471
There's some things that I use repetitively in apps.

00:58:56.471 --> 00:58:59.264
You know a lot of the whole, whether you have the.

00:58:59.264 --> 00:59:08.539
Yeah, I create some of the same functions for communicating with web services over and over and over and over again and it's in essence, they're all the same.

00:59:08.539 --> 00:59:13.744
You just pass in different properties with different values, so there isn't a need to.

00:59:13.744 --> 00:59:17.773
You know, have everybody create some of that.

00:59:17.773 --> 00:59:25.786
I call that basic stuff, like it's the art of what you're writing isn't the consuming of the web service, right, or the connecting and downloading.

00:59:25.786 --> 00:59:35.447
It's the processing of the data, it's the what you do within the user interface for the customer to makes it better.

00:59:35.447 --> 00:59:38.500
But the task of connecting to a site and downloading the file shouldn't be something that you have to write over and over and over again.

00:59:38.559 --> 00:59:55.012
Just use a library, because we all create our own libraries to do different functions and as I said, there are some libraries which are, which are worthy to, to get integrated into the system app, for example, or whatever, or business foundation or whatever it's right at.

00:59:55.012 --> 01:00:24.273
But there are also some apps which are not worthy to get shipped to each and every customer of Business Central but will maybe be worthy to ship as a component which can be used for, let's say, 10% of the customers, and it's not worthy to do this in the stock, in plain vanilla, but maybe at some other point.

01:00:25.842 --> 01:00:29.172
No, I do like that and I like the approach that they're taking.

01:00:29.172 --> 01:00:42.909
Forget of having them automatically installed or not, with some of the the core features they have as separate fun features, and you have to turn the features on or off, or you have to turn, you know, enable the apps, install the apps or not.

01:00:42.909 --> 01:00:49.865
I like the ability to have separates because, like you said, not everybody needs contract management in their business central environment.

01:00:49.865 --> 01:00:59.001
Um and uh, you know, sometimes introducing some of these apps may create issues for environments.

01:00:59.001 --> 01:01:04.862
So I like the option to be able to choose the features that I want, even with the shopify integration.

01:01:04.882 --> 01:01:08.472
Shopify integration is a great application, but it's not relevant for everybody.

01:01:08.472 --> 01:01:10.869
So why have it running?

01:01:10.869 --> 01:01:11.972
Uh, why haven't go through it?

01:01:11.972 --> 01:01:25.882
Because even some of these, if you look at some performance analysis, some of these great extensions, such as contract management, show up in any function that you're doing, such as posting a sales order, which you know doesn't even use contracts.

01:01:25.882 --> 01:01:28.987
So you're right, absolutely.

01:01:28.987 --> 01:01:32.710
Sometimes I'm right, not always, just sometimes.

01:01:32.710 --> 01:01:35.795
It's my new tradition to be correct on Friday.

01:01:38.121 --> 01:01:38.864
Okay, so that simplifies things.

01:01:38.864 --> 01:01:48.989
So, from an ISV point of view, they can publish their stuff on a NuGet feed, somewhere that we'll have to have a longer conversation sometime on how I could do that.

01:01:48.989 --> 01:02:03.588
But for the consuming of that, your ALGit extension for Visual Studio Code can simplify the consumption for a user such as myself because it reads the dependencies in the app file.

01:02:03.588 --> 01:02:05.166
It will go look for the feed.

01:02:05.166 --> 01:02:15.788
You have the standard feeds in there for your applications as well as Microsoft's, and then the ability for a developer to put in a path for the other extensions.

01:02:15.788 --> 01:02:21.202
And if you can't find an extension, then it just goes to Business Central, the Business Central environment as it was.

01:02:22.465 --> 01:02:22.706
Yeah.

01:02:23.447 --> 01:02:26.413
Yeah, excellent, excellent.

01:02:26.413 --> 01:02:26.994
I like this.

01:02:27.280 --> 01:02:28.364
I want to play with this more.

01:02:28.364 --> 01:03:08.512
I'm going to do some experiment with this and now I understand this NuGet lifecycle Well, sir, thank you for taking the time to explain this to me and make it much easier for me to understand how NuGet is going to help myself and other AL developers with their continued creation of Business Central extensions, and I appreciate you creating that tool to make it easier, because when we were talking about it, I understood the process and the theory, but it sounded like it was going to be complicated to be able to put all this together to download these NuGet packages, and I appreciate you creating such a wonderful tool for everyone to use.

01:03:09.780 --> 01:03:11.407
I commend you for taking the time to do that.

01:03:11.407 --> 01:03:16.670
Yes, we're all limited in time and you putting that effort in it helps the world.

01:03:16.820 --> 01:03:18.887
Well, let's go back to what we started talking about.

01:03:18.887 --> 01:03:20.887
You know, time's the most precious resource.

01:03:20.887 --> 01:03:27.608
Once you use it, you don't get it back, and you're spending your time to do that, to save time for everybody else, to give us the opportunity to do better.

01:03:27.608 --> 01:03:34.487
You know, do different things with our time, so I appreciate that and you know anybody else that has some of those extensions.

01:03:34.487 --> 01:03:43.407
If anybody would like to learn more about the applications that you have, about NuGet or ALGet, what's the best way to contact you?

01:03:44.382 --> 01:03:47.371
I think the easiest way is directly through our website.

01:03:47.371 --> 01:03:59.889
As I said, I'm the founder of the company, so I will always be available for anything, even if it's the community-driven things like ALGAD, but also our commercial stuff.

01:03:59.889 --> 01:04:02.666
So it's our website 365businessdevcom.

01:04:02.666 --> 01:04:14.860
Dev like development and, yeah, I'm also happy if anyone will jump into ALGET and contribute.

01:04:14.860 --> 01:04:25.268
So it's, of course, open sourced and it's published on github and if you see some issues, just report them.

01:04:25.268 --> 01:04:26.338
I will be very happy.

01:04:27.061 --> 01:04:44.726
I currently work for the first work for for for the first not preview release, for the first uh real one which, which a lot of things um in in background have changed, and also with um, yeah, some preparations for for devops, um tasks.

01:04:44.726 --> 01:04:57.043
So I will also ship an an um open source devops tasks, devops extension to um, which which fits perfectly into the bc world.

01:04:57.043 --> 01:05:09.014
You can basically use the, the nuget uh task in devops as well, but they have some some um garbage which will be left over on the build server and I don't like this.

01:05:09.014 --> 01:05:25.311
That's why I did a own one, an own task, but it will be also free of charge and just will be available for everyone who likes and I would be very happy for any contribution if it's an issue which is reported or whatever.

01:05:27.545 --> 01:05:40.552
No, that's great that you're making that available for the community and making it easier for everybody, and also it's nice that it's open source, similar to what we just talked about to have libraries that the community can use and others can contribute to.

01:05:40.552 --> 01:05:43.889
So again, thank you again for all that you do.

01:05:43.889 --> 01:05:55.527
Thank you for creating such an extension to help AL developers in the business center world, as well as giving us a crash course on NuGet and how it can benefit us.

01:05:55.527 --> 01:05:59.505
It's our pleasure.

01:05:59.579 --> 01:06:02.427
We appreciate your time and I hope that you have a great holiday season.

01:06:02.427 --> 01:06:11.527
We'll have to have you back on again to follow up on this NuGet when you add all those great tools and maybe we can go through a process or an exercise screen share.

01:06:11.568 --> 01:06:14.518
Yes, I really would like to see now how this works.

01:06:14.577 --> 01:06:17.449
I visualize it, but now, next time we'll go through the process.

01:06:17.449 --> 01:06:20.882
Maybe we can teach you know an old dog new tricks, as they say.

01:06:20.882 --> 01:06:23.753
But with that, I hope you have a great holiday season, sir.

01:06:23.753 --> 01:06:25.139
Enjoy the time with your family.

01:06:25.139 --> 01:06:29.878
It's well deserved and it's also important, and I look forward to talking to you soon.

01:06:29.878 --> 01:06:32.284
Ciao, ciao, bye Later, chris.

01:06:32.284 --> 01:06:40.822
Thank you, chris, for your time for another episode of In the Dynamics Corner Chair, and thank you to our guests for participating.

01:06:41.164 --> 01:06:42.704
Thank you, brad, for your time.

01:06:42.704 --> 01:06:46.148
It is a wonderful episode of Dynamics Corner Chair.

01:06:46.148 --> 01:06:49.646
I would also like to thank our guests for joining us.

01:06:49.646 --> 01:06:52.688
Thank you for all of our listeners tuning in as well.

01:06:52.688 --> 01:07:07.286
You can find Brad at developerlifecom, that is D-V-L-P-R-L-I-F-E dot com, and you can interact with them via Twitter D-V-L-P-R-L-I-F-E.

01:07:07.286 --> 01:07:20.606
You can also find me at matalinoio, m-a-t-a-l-i-n-o dot I-O, and my Twitter handle is matalino16.

01:07:20.606 --> 01:07:24.253
And you can see those links down below in the show notes.

01:07:24.253 --> 01:07:25.623
Again, thank you everyone.

01:07:25.623 --> 01:07:27.168
Thank you and take care.