Dynamics Corner

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

• Christoph Krieg • Season 3 • Episode 354

Share episode

uGet what you pay for! 😄 In the latest episode of Dynamics Corner, Brad and Kris sit down with Christophe Krieg to learn all about the benefits you can get with NuGet. Learn how this app is revolutionizing the development process, making it smoother and more efficient than ever before.
🌟 Highlights:

  • The challenges of managing containers and how to enhance productivity in app development.
  • Why simplicity in app design and NuGet packages create for efficient development workflows.
  • How NuGet integrates with AL and how to navigate the NuGet ecosystem.
  • The potential for community-driven libraries to enhance development.
  • The future of AL development and the need for flexibility and collaborative approaches in building extensions and libraries.
  • The potential of open-source contributions.

🎧✨If you're looking to level up your app development game, this is a must-listen to episode. 

Send us a text

#MSDyn365BC #BusinessCentral #BC #DynamicsCorner

Follow Kris and Brad for more content:
https://matalino.io/bio
https://bprendergast.bio.link/

Speaker 1:

Welcome everyone to another episode of Dynamics. Corner Is nougat a candy in a package. I'm your co-host, chris.

Speaker 2:

And this is Brad. This episode was recorded on December 20th 2024. Chris, chris, chris, finishing the year, up coming into the holiday season, I think of that nougat, nougat in a candy. It's a holiday candy, isn't it? I think I don't even know. You have to ask ChatGPT or some of these other models to see exactly what a NuGet is. 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.

Speaker 1:

With us today, we had the opportunity to speak with Chris Krieg. I was going to make a comment that Chris Krieg sounds like Kris Kringle. I was going to say that during the episode who brought in a candy called Nougat on a Christmas gift.

Speaker 2:

Good afternoon, good morning. How are you doing, sir? Great, how about you? Excellent, excellent. I'm a little tongue-tied this morning for some reason. I guess it's just.

Speaker 1:

It's Friday, it's.

Speaker 2:

Friday and for the most of us.

Speaker 3:

it's the last day before Christmas, the last birthday.

Speaker 2:

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. I know many people have, you know, tried to sneak to get those extended vacations. You know, if you take monday off, I know a lot of places are closed on the 24th or some, uh, close early. So everyone's trying to get those breaks in, or that two week break, excellent, excellent. How about yourself? Are you doing anything interesting for the holiday season besides working? Besides working?

Speaker 3:

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.

Speaker 2:

Time is important. Time in general is important. 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. 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. And everybody says do what you enjoy. Sometimes I enjoy working. Right, it sounds crazy, but sometimes I'm working on something you know from the development point of view.

Speaker 1:

It depends what kind of work you're talking about.

Speaker 2:

Yes, and people say, oh, you're working so much. I'm like well, I enjoy it because I'm fulfilled doing what I do. I'm fortunate that I'm one that enjoys what I do on a daily basis.

Speaker 1:

Well, that's your purpose, right? Sometimes purpose brings that.

Speaker 2:

So is that really? You know it factors into time anyway, but I hope you have a relaxing holiday season. It's and also welcome back. It's been a while since we spoke to you.

Speaker 3:

Absolutely yeah.

Speaker 2:

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.

Speaker 3:

VS Code app. Yeah, yeah.

Speaker 2:

Yes, vs Code app Excuse me not app. Jeez, it's Friday. So just right now, just forget. This is why we don't do Fridays.

Speaker 1:

We keep saying not to do Fridays, but Fridays sometimes kind of creeps into our schedule.

Speaker 2:

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. 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. But before we get into that, would you mind telling everyone a little bit about yourself?

Speaker 3:

Yeah, sure, yeah, my name is Christoph. I'm founder of 365 Business Development. 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. 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.

Speaker 3:

Oh, he had to go there. 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. 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. 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. 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.

Speaker 3:

No, I like that.

Speaker 2:

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. Sometimes to be successful, you just need to handle some of the basics. Process is sometimes a little better than creating this whole big thinking. We need a big, robust system or, you know, complete module, as you would, within the application to do, you know some fancy things. 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.

Speaker 3:

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. 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. On the surface it's just one, two pages and seamlessly integrated into BC, but in the background it's much more. Of course, it's like an iceberg, exactly.

Speaker 2:

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. So they're smaller, compartmentalized tasks in a sense, or they do specific functions and they do those functions very well. See, that's what I've always been told Do what you know and do it well, right. So you can't do everything. So you have a new app within the visual studio, not app source, but within the visual studio marketplace. I get confused and I think it's an interesting app. What is that application that you released recently?

Speaker 3:

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. Opportunities and we could use it. 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. From from this point on it, it was great, but actually nobody does. 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.

Speaker 2:

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. I know NuGet's been around. I've heard about it with other application languages and it's been around for quite a period of time. 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? Is that NuGet, nugget, whatever they call that stuff that fills some of those chewy candy bars, but with that? So let's just take it back a step.

Speaker 2:

So NuGet is a distribution system for packages. Can we talk about that a little bit deeper? System for packages, can we talk about that a little bit deeper? Like, how does it work? You know we have this distribution system. How does it get the information? How does it work? 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. There's a lot in that conversation right there, so I hope you have time.

Speaker 3:

I have I have time, of course Well. So Nougat is basically a standardized format on how to distribute artifacts, to be as common as possible, to distribute artifacts for multiple platforms. So it's very, very popular in C-sharp or NET, but it's basically not focusing on one specific language. And what NuGet basically is is a server. You can host it yourself. You can use Azure DevOps, for example, azure DevOps feeds, which are also capable to serve as a NuGet server. Or, of course, you can use NuGetorg to publish and distribute your packages.

Speaker 3:

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. I don't know, for example, a manifest or something like this. It's a special package which is called NuGet package N-U-P-K-G. 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? Uh, or which one, which is the available version right now, which dependencies you have and and all this stuff. And this is all pretty common in in bc world as well. So it was pretty natural to to adapt to this instead of we invent the wheel and what this basically brings to our table. I think it's not that important to understand what NuGet packages are. 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. But you don't really need to understand what's technical inside of a NuGet package. 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.

Speaker 3:

Let's say it's this way because in this case we are a little special, because we have a publisher name. This publisher name can change over the versions. We have an app name. This app name can change it versions. We have an, an app name. This app name can change. It's not a breaking breaking change. 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. So they had to thought about, okay, how we name packages. So even people and software can find the packages.

Speaker 3:

And the big question is basically, what can you do with NuGet packages and what brings NuGet to the table for BC development? And I think what's really important to understand is what type of artifacts do we have in BC? And basically we have three types. We have the classic app file with source code included. 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.

Speaker 3:

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. The server recompiles it and uh, or compiles it into into c sharp and runs this on the on the gc server. Great runtime packages, as I said, are pre-compiled, so you don't have to do this, this compilation process again. But symbols are only references. 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.

Speaker 2:

Yes, so you can see the structure without seeing the code. 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.

Speaker 3:

We all know the command download symbols, but basically download symbols is not always true. 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. 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. The only thing you need is the symbols, and this is a pretty interesting thing for ISVs and also for Microsoft itself. So let's start from another point. When we start to develop a VS Code app, what do we need? 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. All this stuff, all these we need the symbols basically.

Speaker 3:

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. 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. Container and do all this stuff again and again, and again and again. 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. Yes, so so what? Yeah, so what you're?

Speaker 2:

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. See Friday, here we go. So we download the symbols for that version. 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.

Speaker 2:

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. Yes, and creating the. You know it downloads the artifacts to create the container. Then now you have to download your symbols, build your application, publish your application, get the runtime package.

Speaker 3:

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. I know I'm a lazy person, definitely.

Speaker 3:

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. 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. That was the basic idea. I don't want to create a container over and over again. 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.

Speaker 2:

Smart choice. By the way, that was a very smart choice to move to Mac. I'm not sure, but oh, we might have to end the conversation early.

Speaker 3:

You'll get there. Maybe I need some more time. Yeah, however, the container stuff was really a problem for me and I thought, okay, how can I solve this? And the first idea which was a pretty bad idea was to just commit the AL packages folder into my repository.

Speaker 2:

Ah, bad idea.

Speaker 1:

Cringe Really bad idea, I just cringed.

Speaker 2:

I just cringed when I heard that, because talk about wasted space. I even share my AL package folder across projects and workspaces because I only need a. You know, I found one time on a computer where someone had the al packages for each project, never mind the workspace. Right, you can. You know the workspace has the setting. You can use the al packages and then individual projects. 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. I think it was like 17 gig or something.

Speaker 2:

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. 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. It's a lot of space.

Speaker 3:

But, as I said, I was in the problem. I had a Mac container that doesn't work.

Speaker 2:

Oh, the Mac is not the problem with having to check in the same place. Yeah, I know, don't try to blame the Mac. No, no, no, no, no, but, no, no, no, no, no, no, but it was my starting point.

Speaker 3:

So it's just the start of a journey. Yeah, and, as I said, I recognized very, very fast that's not a good idea to do. 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. And then I thought about okay, how you can do this? 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. It's intuitive.

Speaker 3:

So why not keep this as a template and try to do this in VS Code as well? 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. 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. But, um, the most important thing for me is that it's not just about about local vs code development. 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.

Speaker 2:

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. It could be from an ISV it could be from Microsoft.

Speaker 3:

At least two extensions are always in place it's a system app and application itself.

Speaker 2:

So at least two dependencies so that way you can build based on it for a specific version or even just the latest version. So by putting in the NuGet path right to download the AE which we can talk about how that works in a moment. So when you're going to build, you basically put a reference for the dependency. 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.

Speaker 3:

And create a container and as long as you don't want to execute tests in, execute uh tests in it. It's, it's fine and uh, what I? What I tried as a some prototype it's not, it's not ready yet for cicd purposes is back in the days. We now have, I think, seven or eight apps and back in the days, uh. 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. And right now it's still working with our time frame in the night. 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.

Speaker 3:

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.

Speaker 3:

I don't need to use this for each and every app.

Speaker 3:

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. 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. 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. 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. 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. I don't know, eight times in my situation or eight times.

Speaker 2:

Three, basically because you're doing the current the next minor, the next major, so you're doing three builds in essence for each. 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. And is that the intent? 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?

Speaker 3:

um, you know, basically, basically, we have, we have, we are. We are very focused on just having one code base for all the bc versions we are. We are supporting we're not just supporting cloud which this for all the BC versions we are supporting. We're not just supporting cloud, this would be way too easy. We're also supporting on-prem and so typically we are supporting from BC 18 to the latest version. So what we do to master this is we are working a lot with preprocessor symbols, so compiler directives and say if bc.

Speaker 2:

By the way, blah, blah, blah.

Speaker 3:

So, and this is working pretty pretty well, but it's it limits us, of course. For example, if you want to use namespaces in our, in our apps, um, we need a lot of this hashtag. 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. We store them forever. Why, to be honest, I don't know why. I decided this sometime and never thought about it again.

Speaker 3:

But, yeah, you see all the packages in NuGet and you can reference to it. 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. 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. But that's not relevant, but it's more like a sitemap from a website. So you come there and you say, okay, I'm looking for 21 point whatever. And it say, okay, go this. Say okay, I'm looking for 21 point whatever. And it say, okay, go this way. I'm looking for 25 point one. Okay, go this way.

Speaker 2:

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. Can you send it to me? 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. In that case, would it be the entire runtime version or just the symbols?

Speaker 3:

That's up to the publisher basically. 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. But I also know one publisher which just chips symbols over the NuGet feeds, but that's also fine.

Speaker 2:

Okay, it's up to the ISV how they like to distribute it. 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. Based upon that, I want to get into your app because this sounds like a lot. I understand the process now of what it does. 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. So how does it know the validity of the package? It may or may not be such a case with you know some business central development or not, depending upon what the application does. 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? 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?

Speaker 3:

Yeah, that's a problem. 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. 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. It could be anything. But all the Microsoft itself has three NuGet feeds right now. One is for Microsoft symbols, one is for Microsoft apps and one is for AppSource symbols. So each and every AppSource app is already published by Microsoft in the latest version. 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.

Speaker 2:

So Microsoft? So they have a server themselves for their symbols. It's basically DevOps.

Speaker 3:

It's a DevOps instance, Azure DevOps instance, and they are serving us a public NuGet feed from well. Three public NuGet feeds, basically, from there.

Speaker 2:

Including all the apps in AppSource. For the latest version of the app that's in AppSource.

Speaker 3:

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. As an AppSource publisher, you don't have to care about all this stuff.

Speaker 2:

That's pretty cool.

Speaker 3:

It is definitely Now I'm anxious to know how I use all of this and, additionally, a lot of ISVs. To be honest, currently it's a little wide west, so there are naming conventions. It's pretty much the same, like the early days in AL. 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. And in NuGet it's pretty much the same. 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.

Speaker 3:

And, as I said last year at Tech Days, I heard more or less the first time from this topic. So it's five years later. 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. 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. Go there, there's your apps, select your version, click download.

Speaker 3:

Happy, but this is the old one. Uh, when we started to adapt to to new get, we will. We will deprecate the site and completely switch to new get because it's much easier to maintain for us. But, um, we all the publishers, had the problem. Okay, how do we serve customers, other partners, with our packages in certain versions which are not in Epsos? And they all invented clever solutions, but it is how it is. When you ask 10 people, you got 13 answers how you can do things.

Speaker 2:

And that's how it is currently.

Speaker 3:

So naming conventions from the packages is pretty important for software. We have a manifest and, in best case scenario, we have an app ID. We have the publisher name and we have the app name. As I said, publisher name and app name are fluent. They can change over the time. 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?

Speaker 2:

Yeah, right Depends it depends. 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. 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. And this was for version 25. So I updated the version 25.

Speaker 3:

Yeah, it's the same with me. I'm lazy, as I said, and, um, yeah, then you have to. You have to think okay, how can the software determine which version is? Is what you're looking actually looking for? When you just have one container where you specified which version the container is running off? 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. 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. So some partners I know about are just using the BC numbers so 25.1, 25.2, and then their version is following. Some are completely in their own number range, so it's tough for a piece of software.

Speaker 2:

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. One thing we talked about from an ISV point of view you had mentioned. Or from ISV point of view you had mentioned, or from a consumer point of view. I do want to talk about how to consume this right. I understand the process now as far as conceptually how it works. 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. If I'd like to host my own, you said I could set it up in DevOps. Right, is what you use for an example. What if I don't want to host my own? Does my only option NuGetorg? Does Microsoft have something? 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?

Speaker 3:

are different providers. The most common is basically NuGetorg. 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.

Speaker 2:

But what you have to keep in mind is the only reference we have is the app ID.

Speaker 3:

So when you download using NuGet, basically we are looking for the app ID using NuGet, basically we are looking for the app ID. 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. It doesn't need to prefix with Microsoft, so it's not secured. 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. 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. The app name, dot. Maybe symbols, dot, maybe country code, dot. App ID at the last. And if you have these components in the name we can make the software. For example, my extension, or also NuGet. The NuGet executable itself can make pretty sure that you are running against the right publisher. But when you're just seeking with the app ID, that's not that much of a problem.

Speaker 3:

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. And if we serve more and more tools Freddie did a great job in VC Container Helper. 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. 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. We have DevOps and all the others too.

Speaker 2:

Okay, so now we have multiple feeds that are available and the authenticity of a NuGet package. It's not just an AL thing, that's just the way NuGet works in general. So I just wanted to point that out. 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.

Speaker 2:

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. So I have those three dependencies right from the beginning. 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. So I have to use yours as a dependency. I'll subscribe to event and do something. How do I get it and how do I know where it is? And then, how do I get it within my application?

Speaker 2:

Because now, as you talked about, I could create a container. I get the symbols from you or I. You know, I download it into my. If it's an online environment, I can install it in the online environment. If it's a container, I get the package and install it, download my symbols and that symbol is there. 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. I'm going to a NuGet feed. How does that work? That is where now I'm stuck. How do I know to go to this post office box to get the file for this particular version? How do I do that as an AL developer?

Speaker 3:

Basically, as an AL developer. There's no difference. The only thing which changes is the command you executed. So you're not hitting AL download symbols. Instead, you may hit restore Nuget packages. And what happens? The NuGet package will be downloaded. 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.

Speaker 2:

So the only thing I have to do is rebuild NuGet packages. Restore yeah, basically, oh, restore, but is that with? Okay, I want to talk about your extension soon, but is that within the AL language to restore NuGet packages?

Speaker 3:

That's within your extension. Yes, what I did, and that's also what Patrick did, was this NuGet helper extension.

Speaker 2:

Okay, so now. So within your extension, what's the name of the extension that's in the VS Code marketplace, if anybody wants?

Speaker 3:

to search for it.

Speaker 2:

ALget AL not.

Speaker 1:

NuGet.

Speaker 2:

ALGET, alget, alget. Okay, so with ALGET, I install the extension. The ALGET will look at the dependency in my app file and then, based on that dependency, how does it know where to go?

Speaker 3:

And then, based on that dependency. How does it know where to go? So built in or baked into the extension. 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. 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. 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. And then it looks there and says, okay, maybe I find something, and then it downloads it basically oh, okay. So that makes it much easier.

Speaker 2:

So in your settings, I'm sorry so in your settings you can specify the additional feeds to work with. 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.

Speaker 3:

What do you say Rebuild? I always want to say rebuild, restore. I knew it wasn't rebuild, so I just recycled it.

Speaker 2:

No, no, it's good, it's good, I'll have to get the restore. So if I click restore, it works. I like that. So then if I have a dependency with an ISV or somebody else, I would ask again. 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. Oh, that makes it so much easier. See, now I don't even need to understand this.

Speaker 1:

It's like Lego pieces, right, Like it's just like it's. It's uh, you, you're building something and it's like yeah, I need something very specific. 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.

Speaker 3:

And what's a? What's a? Pretty sounds like that.

Speaker 3:

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.

Speaker 3:

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. 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.

Speaker 2:

I think of, like the type helper code unit. I think of some of those, what I call those utility libraries. A lot of individuals make utility libraries that are available on GitHub that I could download and use and incorporate. But in what you're saying I like that idea. 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. 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. So I agree with you At that point. It's not a marketplace right or an app source gallery.

Speaker 1:

It's like Amazon.

Speaker 3:

I like what you said with Lego. It's pretty much like Lego. 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. 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. So it's great, but not everything belongs into a system app no, I agree with you there.

Speaker 2:

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. It's their application justify that don't fault them right, they don't have.

Speaker 2:

Nobody has the resource you know the resources, whether it be dollars or talent to do everything for everybody. Right, so they have a timeline for what they're working on with the application. 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. 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? How can I consume API endpoints within Business Central? 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. I like that idea, see.

Speaker 3:

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. Oh, forget, it prevents from doing this right now.

Speaker 2:

And that's basically the object ID. So, oh, forget it, I'll be. I was hopeful that that object ID would go away many years ago.

Speaker 1:

I thought they'd been talking about that for a while now.

Speaker 2:

You know from what I see and hear and what I read, right, everything you read on the internet is true is. 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. Part of me just wants to say just do it. You know we're getting to the point where you know we have. You know, naming collisions is something we have to look at. We have to look at object id collisions. They're still both unique. There's like we have now multiple unique identifiers for an object, which is limiting. So I would love to get rid of the object id. 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. You don't have that limitation because you still can work between the 50 000000 and 99,000 range.

Speaker 2:

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. 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. In that time, that's what I would like you know, we should have. You know, chris, next year we have to put a note, we need to have. What are your 12 wishes for Christmas? 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.

Speaker 3:

I would say save this wish for the next two years. I think that's.

Speaker 2:

You think two years maybe two years we see it developing very very fast.

Speaker 3:

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.

Speaker 3:

This is preventing uh from from shipping libraries, because when you develop a library you have to. Okay, what object idea did I take for this? And how do I make sure that in my customer tenants it's not already taken by PTE or by whatever?

Speaker 2:

Whew, it's tough. Yes, I see Good luck. 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. Two years. We'll talk and see if it's going.

Speaker 3:

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. We got a lot of things. We got a lot of cool things. We got interfaces, namespaces we still have prefix and suffix, but at least we have namespaces now.

Speaker 2:

I think maybe the namespaces will help speed that along, because now we're getting more and more conventional with the development within al. 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. 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.

Speaker 3:

Well, in my career, as I said, it's in my wildest dreams. 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.

Speaker 2:

There's some. There's some things that I use repetitively in apps. You know a lot of the whole, whether you have the. 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. You just pass in different properties with different values, so there isn't a need to. You know, have everybody create some of that. 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. It's the processing of the data, it's the what you do within the user interface for the customer to makes it better. 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.

Speaker 3:

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. 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.

Speaker 2:

No, I do like that and I like the approach that they're taking. 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. I like the ability to have separates because, like you said, not everybody needs contract management in their business central environment. Um and uh, you know, sometimes introducing some of these apps may create issues for environments. So I like the option to be able to choose the features that I want, even with the shopify integration.

Speaker 2:

Shopify integration is a great application, but it's not relevant for everybody. So why have it running? Uh, why haven't go through it? 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. So you're right, absolutely. Sometimes I'm right, not always, just sometimes. It's my new tradition to be correct on Friday.

Speaker 2:

Okay, so that simplifies things. 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. 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. It will go look for the feed. 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. And if you can't find an extension, then it just goes to Business Central, the Business Central environment as it was.

Speaker 1:

Yeah.

Speaker 2:

Yeah, excellent, excellent. I like this.

Speaker 2:

I want to play with this more. 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.

Speaker 1:

I commend you for taking the time to do that. Yes, we're all limited in time and you putting that effort in it helps the world.

Speaker 2:

Well, let's go back to what we started talking about. You know, time's the most precious resource. 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. You know, do different things with our time, so I appreciate that and you know anybody else that has some of those extensions. 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?

Speaker 3:

I think the easiest way is directly through our website. 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. So it's our website 365businessdevcom. Dev like development and, yeah, I'm also happy if anyone will jump into ALGET and contribute. So it's, of course, open sourced and it's published on github and if you see some issues, just report them. I will be very happy.

Speaker 3:

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. So I will also ship an an um open source devops tasks, devops extension to um, which which fits perfectly into the bc world. 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. 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.

Speaker 2:

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. So again, thank you again for all that you do. 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. It's our pleasure.

Speaker 2:

We appreciate your time and I hope that you have a great holiday season. 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.

Speaker 1:

Yes, I really would like to see now how this works.

Speaker 2:

I visualize it, but now, next time we'll go through the process. Maybe we can teach you know an old dog new tricks, as they say. But with that, I hope you have a great holiday season, sir. Enjoy the time with your family. It's well deserved and it's also important, and I look forward to talking to you soon. Ciao, ciao, bye Later, chris. Thank you, chris, for your time for another episode of In the Dynamics Corner Chair, and thank you to our guests for participating.

Speaker 1:

Thank you, brad, for your time. It is a wonderful episode of Dynamics Corner Chair. I would also like to thank our guests for joining us. Thank you for all of our listeners tuning in as well. 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. You can also find me at matalinoio, m-a-t-a-l-i-n-o dot I-O, and my Twitter handle is matalino16. And you can see those links down below in the show notes. Again, thank you everyone. Thank you and take care.

People on this episode

Head Shot

Kris

Host
Contributor

Brad

Co-host