Consider changing SourceBrowser.Generator to a library
Closed this issue · 13 comments
Currently the Generator is a console-application (well Program.cs is not really implemented, so not sure if you are using it as console-application). But in my opinion a DLL would be the cleaner output, since it can then be put on nuget and reused in different places.
There should still be a console-application (SourceBrowser.exe, SourceBrowser.Generator.Console.csproj) which takes two parameters (solution path and output path) and passes it to the lib. The console-application should then be pushed to chocolatey
Good idea. I'll take that. I'll create the console application in the same solution.
Created SourceBrowser.Generator.TestConsole in 17426af because name Console interfered with .net's System.Console
I will create a pull request once I resolve an error with reflection which is probably unrelated.
Agree Console was not a good idea, but TestConsole seems like it could only be used for tests, but I would see the use case for a console application e.g. in a build process of some business which want to generate static html pages.
So maybe any of SourceBrowser.Generator.Exe, SourceBrowser.GeneratorExe or SourceBrowser.GeneratorConsole would fit better?
You're right about TestConsole.
How about we get down to essence and call it SourceBrowser.Generator.ExeWrapper or SourceBrowser.Generator.Exe?
I proposed SourceBrowser.Generator.Exe too so go for it!
But make sure the name of the exe is SourceBrowser.Generator else the resulting exe will be SourceBrowser.Generator.Exe.exe
As I was renaming the .exe to SourceBrowser.Generator.exe I realized that we shouldn't give the exe the same name as the class library, as these are different assemblies.
I called the sample project SourceBrowser.Samples, as this project is used to show sample usages of SourceBrowser, including the Generator module and possibly other modules.
Again you are right but I don't completly agree 😄
I have still the opinion, that SourceBrowser should provide next to the Website a executable which can be used as standalone to create static pages.
But I don't want to 'block' the project because of such a detail. So keep it it as Samples and I will open an issue for a standalone application when the project is more mature. 👍
You're right, there is more to this project than using it solely for demonstration. @JoshVarty what do you think?
Actually, right now we are blocked on this issue: http://stackoverflow.com/questions/26535207/best-method-for-deploying-projects-relying-on-roslyn-dlls
MSBuild doesn't quite work when it's originally invoked from within another project, because it's expecting dlls in the bin/ folder of the invoking project. They exist only in bin/ of SourceBrowser.Generator and are not copied over because we don't use them directly in SourceBrowser's code.
The .NET ecosystem and dependency managment... 😢
Following the concepts of NuGet, SourceBrowser.Samples should have the same dependencies SourceBrowser.Generator. If you create a NuGet package for SourceBrowser.Generator (nuget pack SourceBrowser.Generator.csproj) the resulting package will have depencies to all Microsoft.CodeAnalysis.* packages, which means when you are installing SourceBrowser.Generator package to any other project, the target project will have a direct depencie to SourceBrowser.Geneator and all its depencies.
In our case (and in the case of millions other .NET developers) it is not feasable to create a NuGet package every time pressing F5, so SourceBrowser.Samples has a project reference (and not a NuGet reference), which result in loosing the depencie 😢
IMHO the less ugly solution is the have a depencie to the Microsoft.CodeAnalysis.* packages in the SourceBrowser.Samples as well.
This is kind of a related solution: http://stackoverflow.com/questions/5418856/nuget-for-solutions-with-multiple-projects
Yeah, Jason Malinowski recommended the same approach: https://twitter.com/jasonmalinowski/status/525392483262672897
It sounds like in the future we might not have to do this, but at the present time we'll have to add all Microsoft.CodeAnalysis.* references to any project that references SourceBrowser.Generator.
Yep, the ASP.NET vNext build system/runtime doesn't make a difference between a project reference and a NuGet package. This will do everything a lot easier.