I'm a complete newbie to MSBuild and I want to use it over NANT.
What I'm wanting is to run a build in say debug mode and to use app.configA, then in Stage use app.configB and in Production use app.configC.
I presume this is all doable but can anyone point me in the direction on how to set this up?
If you can endure the excruciating pains of MSBuild's copy statement, then you can do something like this as a post-build event:
<Copy Condition="'$(Env)' != ''" SourceFiles="$(WhereverTheDeployedAppIs)\web.$(Env).config" DestinationFiles="$(WhereverTheDeployedAppIs)\web.config" />
Now let's go through that.
$(Env) is the environment. You'll have to pass that in via your build script.
SourceFiles is set to the config file's original name (Web.MyFavoriteEnvironment.config, for example).
DestinationFiles is set to the same thing, only shortened to Web.config, overwriting whatever Web.config was there before. This is what your app will use.
Massage this to your app config file naming convention.
Now...
Although (something like) this works for my team, I really hope, for your sake, that someone posts something better.
Related
If one has a running .net core web app and there are multiple appsettings.json files in the root, how can you tell what environmentname is set to? I guess one way is to write your own utility or status page where you use code to write out the value of this variable. Is there another way?
Instead of using some sort of transform as in the case with web.config files, you now generally deploy all the environment-specific appsettings files, and let the app determine the value of the environment. This seems kinda confusing, in that you no longer can simply look at a config file and know what settings the app is using.
You can check the value of IHostingEnvironment.Environment as William suggested in the comments, but a better approach would be to call either IHostingEnvironment.IsDevelopment() or IHostingEnvironment.IsEnvironment() and it will do the name checking for you.
Methods for checking for production (IHostingEnvironment.IsProduction()) and staging (IHostingEnvirionment.IsStaging()) exist as well.
Recently, my company started to focus Extension_v2 development for Dynamics NAV BC. We store our code in an internal Git-Server. So far, so good.
But startig a new project is still a very fiddly task. You have to create a repository, clone it, execute the AL Code-Task, move the files to the fitting location push the repository to the correct upstream etc. And all this does not include the first initial Steps (README, CHANGELOG and all other fundamental files...).
So I wanted to write a small PowerShell-Script, to do all these initial steps before being able to start working on the Project.
The Problem: I could not find a way to execute the "AL-GO!" task via script.
I have already searched the Internet and some forums for an answer... but it seems like microsoft did not consider the possibility to execute tasks from the AL-Language-Extension via script.
I also played around with the New-NAVAppManifest and the New-NAVAppManifestFile command for the old Extension_V1 development, but that did not do the trick.
I am looking for a fair and easy way to combine the creation of the app.json file and the launch.json file with other commands to easily initialize a new Project without haveing to write all commands manually. Maybe I did not recognize the easy solution. Or maybe this is just the way we have to do it in Extension_v2.
Anyway, thanks for all your help nevertheless.
Greetings.
Stay away from Ext V1. It's highly deprecated at this point.
First of all, why do you need to execute the "AL-Go!" via script? The "AL-Go!" command should already include all necessary steps to create an empty project including the launch.json and app.json. (minimal adjuments required dependent on your BC environment)
There is an extension/plugin for Git in Visual Studio Code which will handle all the repository stuff for you. You don't need to change file locations if everything is set up for Git. I rarely use it yet, but saw a demo for it on the Directions EMEA last year and I'm pretty sure it works at its current state (someone correct me if I'm wrong)
A way to implement the "AL-GO!" command for a script or for setting up additional steps in your project setup might be to write your own visual studio code extension/plugin which requires some additional know-how for that.
OR
You just change the settings/files of the default project, I bet there is at least a file for creating the initial AL project. Just change that to your requirements
I am using the Intellij 11.1.5. We are a large team, and have a pretty complex project setup. so we've made a template and when someone needs a new project set up, we just clone it and she is pretty much ready to go. One other thing i would like to automate is the creation of run configurations. One such configuration starts a custom bat file that requires a parameter representing a path that is user specific. I wanted to know if can store that value as a path variable specific to each project. Maybe somewhere in the .idea folder in my project. I know that Intellij stores it in its .IntelliJIdea11\config\options\path.macros.xml file, but is there a way to tweak that?
Any other idea that would allow me to locally store a parameter passed to the run config script would be usefull.
Thanks
I'm afraid you can't do it in IDEA, but you can use some environment variable directly in the .bat file instead of using the parameter (or rewrite the batch script to detect this value automatically, if possible). Instruct your users to define this environment variable.
IDEA Path variables are global and cannot be made project specific.
I have the following need:
I'll have to create an MSBuild task that will produce an xml file, which I then need to embed as a resource to one of the projects being built. How do I change my MSBuild proj to accomplish that? Is there a built-in task I can use for embedding the file, or do I need to create one? If the latter, any direction on that would be great.
Thanks in advance!
Update: based on the suggestions given, I've ended up adding an empty xml file to the project as a resource, creating a simple MSBuild custom task (http://bartdesmet.net/blogs/bart/archive/2008/02/15/the-custom-msbuild-task-cookbook.aspx) that writes content to that file as I need it, and running that task as a "BeforeBuild" target. Works like a charm. Note that I've had to "exclude the file from source control", so it won't get checked out every time I build the project, and I've also added some code to the task to make sure the file isn't read-only (http://www.del337ed.com/blog/index.php/2007/09/05/clearing-the-read-only-flag-on-a-file-in-c/).
If you don't need to create the whole Xml file from scratch and could add a stubb file to your project you could use the XmlPoke Task to update this file in the BeforeBuild Target (see Sergios answer).
You can use builtin in your .csproj/.vbproj file target BeforeBuild (not forget to uncomment it) and call required MSBuild task in BeforeTarget. In that project add that resource as embedded. That's all.
I am using MSBuild extensionpack. I'd like to copy the entire contents of the build directory to another directory on the file system. I do not want to rename the destination directory, just replace the contents. It could be my unfamiliarity with msbuild extensionpack but it seems like this should be easy and I have been unable to find readily available documentation on the web.
I am trying to set up a service that is automatically deployed in the Continuous Integration environment after a successful build.
As far as I remember, you'll need to clear and copy in separate steps. So do the delete/purge first, then copy over. I wasn't able (at the time I last did) to find a way to "overwrite". This actually worked better for us b/c one build may remove files that a previous one contained, so we wouldn't want them to "linger".
To delete, try (assuming DeploymentDesintationPath is a property with the path):
<MSBuild.ExtensionPack.FileSystem.Folder
TaskAction="RemoveContent"
path="$(DeploymentDestinationPath)" />
And then copy (notice you need to populate an itemgroup for both the source and the destination)
<ItemGroup>
<DeploymentSourceFiles
Include="$(BuildFolder)\**\*"
/>
<DeploymentDestinationFiles
Include="#(DeploymentSourceFiles->
'$(DeploymentDestinationPath)\%(RecursiveDir)%(Filename)%(Extension)')"
/>
</ItemGroup>
<Copy SourceFiles="#(DeploymentSourceFiles)"
DestinationFiles="#(DeploymentDestinationFiles)" />
I haven't done this in a few months, so pardon if any of these examples require a bit of tweaking.