1

Topic: Automatic generation of source codes without the manual assembly of the project

All greetings! Prompt - in what place it is possible to thrust code generation on a template (in our case it M4) so that for this purpose it was not necessary manually  the project. I to myself it see so -  MSBuild-taska which  at attempt to resolve dependence which checks that the template file changed and anew generates  in the project source codes. Plus launches FSWatcher which traces changes in this file. But I am done not abandoned by sensation of that is a bicycle and there is more simple and refined decision which works from a box. I will repeat that the variant with the project assembly does not approach - at the person of unknown types at the first discovery of the project for  which it should not be necessary for it  the project.

2

Re: Automatic generation of source codes without the manual assembly of the project

Hello, LWhisper, you wrote: LW> All greetings! LW> prompt - in what place it is possible to thrust code generation on a template (in our case it M4) so that for this purpose it was not necessary manually  the project. I for the similar know 2 variants: - Visual Studio Single-File Generators. The decision is pure Design-Time (and working especially in VS). The generator works while you in studio change a file on which "hung up" the generator. The generated file is added as child to yours (i.e. it will be a project part). A variant with a heap of lacks. For example, it is necessary to change files especially in studio, to debug difficult... - MSBuild generator (actually at this method I do not know an official title and the official description too did not see). Actually, I suggest to use the second variant. It like as explicitly enough is described here, but if in 2 words that  so: - You creates MSBuild task which is able to generate to you the necessary artifacts (let it will be XMLDialogGeneratorTask in the assembly ExternalDSLSamples.dll) - for usage of this Task do special Target a file (let, for example, it is called XMLDialogGeneratorTask.targets). <Project xmlns = "http://schemas.microsoft.com/developer/msbuild/2003"> <! - we Connect the task-> <UsingTask AssemblyFile = "ExternalDSLSamples.dll" TaskName = "XMLDialogGeneratorTask"/> <! - This main target which will be used  oscillations. From important - it takes source files from Items with name XmlDialog. And the files received on an output adds to Items Compile-> <Target Name = "XMLDialogGenerator"> <XMLDialogGeneratorTask ModelFiles = "(XmlDialog)" OutFolder = "obj \$ (Configuration)" Namespace = "$ (RootNamespace)"> <Output TaskParameter = "ResultFiles" ItemName = "Compile"/> </XMLDialogGeneratorTask> </Target> <! Is it is necessary that it was possible to select from a Visual Studio for our file Build Actions with name XmlDialog-> <ItemGroup> <AvailableItemName Include = "XmlDialog"/> </ItemGroup> <! - And it we ours target  in the general build process-> <PropertyGroup> <CoreCompileDependsOn> $ (CoreCompileDependsOn) ;XMLDialogGenerator</CoreCompileDependsOn> </PropertyGroup> </Project> - now, open a file of our project and we do there such changes: <Project ToolsVersion = "12.0" DefaultTargets = "Build" xmlns = "http://schemas.microsoft.com/developer/msbuild/2003"> <! - Here something from the main project-> <! - we Add ours target-> <Import Project = ".\XMLDialogGeneratorTask.targets"/> <ItemGroup> <! - we Register our file which the generation task-> <XmlDialog Include = "DialogSample.xml"> <should ! - We specify that at change of this file it is necessary to cause ours target (at Microsoft) here often costs MSBuild:Compile, but like it it is excessive-> <Generator>MSBuild:XMLDialogGenerator</Generator> </XmlDialog> </ItemGroup> </Project> Actually, at discovery of your project the studio causes recompilation and  to that we were built in build process files will be generated and get to compilation. With the assembly manually too all is clear. And here at change of templates we will work target. And yes, all navigatings on the code and IntelliSense - work (on an extreme measure should - I hope that in Roslyn they did not break it). P.S. Behind prescription of years I already could forget something - so look at article to which I refer well and as a whole look for similar decisions. P.P.S. This decision goes to a section with your initial requirements a little, namely that the generated files are not added in the project - they are connected only in build process. But it seems to me such approach more correct - the autogenerated files all the same nobody will correct (corrections will be lost at the first editing of a template), and presence such  the code confuses more... Well and if it is necessary to look that  enough to open a folder where we save files and to look.

3

Re: Automatic generation of source codes without the manual assembly of the project

Hello, Michael Romanov, you wrote: > Actually, I suggest to use the second variant. It like as explicitly enough is described here, but if in 2 words that  so: > - you creates MSBuild task which is able to generate to you the necessary artifacts (let it there will be XMLDialogGeneratorTask in the assembly ExternalDSLSamples.dll) Many thanks! That searched!

4

Re: Automatic generation of source codes without the manual assembly of the project

Hello, Michael Romanov, you wrote: > <Target Name = "XMLDialogGenerator"> > <XMLDialogGeneratorTask ModelFiles = "(XmlDialog)" OutFolder = "obj \$ (Configuration)" Namespace = "$ (RootNamespace)"> > <Output TaskParameter = "ResultFiles" ItemName = "Compile"/> > </XMLDialogGeneratorTask> > </Target> And how it is possible  operation of this mechanism? (VS2017) <Target Name = "M4CSharpGenerator"> <M4GenerateCSharp InputFilePaths = "(M4CSharp)" OutputDirectoryPath = "obj \$ (Configuration)"> <Output TaskParameter = "OutputFilePaths" ItemName = "Compile"/> </M4GenerateCSharp> </Target> Files are generated in Output added, [Output] public String [] OutputFilePaths {get; set;} it is defined. But happens nothing. Compilation transits, errors are not present, file traces in the assembly too.

5

Re: Automatic generation of source codes without the manual assembly of the project

Hello, LWhisper, you wrote: LW> Files are generated in Output added, [Output] public String [] OutputFilePaths {get; set;} it is defined. LW> but happens nothing. Compilation transits, errors are not present, file traces in the assembly too. If I am not mistaken, Output parameters which will be brought in Items should be not in the lines, and ITaskItem. I.e. something of type (very much ): public class MyTask: ITask {public IBuildEngine BuildEngine {get; set;} public ITaskHost HostObject {get; set;} [Output] public ITaskItem [] OutFiles {get; set;} public bool Execute () {var result = new TaskItem [1]; result [0] = new TaskItem () {ItemSpec = "\obj\Debug\MyFile.cs"}; OutFiles = result. OfType <ITaskItem> ().ToArray (); return true;} } For diagnostics, on idea, the normal broad gull from MSBuild should approach. On how many I remember it there accurately enough shows that was on an input and a task output and also as changed Properties and Items. But I to you recommend to try MSBuild Structured Log - the format of these a den now "from a box" is supported in MSBuild (in what goes with VS 2017 - precisely). Very much it is convenient to look as where did each task (the normal linear broad gull for this purpose where approaches is worse). There basically it is painted as the utility to use - it is possible to launch the project assembly directly from the viewer or at first to collect MSBuild th with /bl, and then to look at result

6

Re: Automatic generation of source codes without the manual assembly of the project

Hello, Michael Romanov, you wrote: Thanks! I will try! Here at start  from under a broad gull he for some reason resolutely refuses to launch generation of files. Also frightens of terrible lines: P roperty reassignment: $ (CoreCompileDependsOn) = "_ComputeNonExistentFileProperty;ResolveCodeAnalysisRuleSet" (previous value: "M4CSharpGenerator;") at C:\Program Files (x86) \Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft. CSharp. CurrentVersion.targets (166,9) Here so took and cut my dependence.

7

Re: Automatic generation of source codes without the manual assembly of the project

Hello, LWhisper, you wrote: LW> Here so took and cut my dependence. It, is similar I a little you deceived. Target-files which do injections in build process, should be connected after those files in which this process is described. In this case - after Microsoft. CSharp.targets. <Project ToolsVersion = "12.0" DefaultTargets = "Build" xmlns = "http://schemas.microsoft.com/developer/msbuild/2003"> <! - here something from the main project-> <ItemGroup> <! - we Register our file which the generation task-> <XmlDialog Include = "DialogSample.xml"> <should ! - we Specify that at change of this file it is necessary to cause ours target (at Microsoft) here often costs MSBuild:Compile, but like it it is excessive-> <Generator>MSBuild:XMLDialogGenerator</Generator> </XmlDialog> </ItemGroup> <Import Project = "$ (MSBuildToolsPath) \Microsoft. CSharp.targets"/> <! - it is better nevertheless here-> <Import Project = ".\XMLDialogGeneratorTask.targets"/> </Project>