Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Samples To Automated Build #26

Open
tomspilman opened this issue Jul 19, 2014 · 5 comments
Open

Add Samples To Automated Build #26

tomspilman opened this issue Jul 19, 2014 · 5 comments

Comments

@tomspilman
Copy link
Member

Fix the build server to build the samples develop branch just like we do the main MonoGame project.

The first issue is how to make the existing projects build against a development build of MonoGame? Currently the samples all do this in their csprojs:

<Reference Include="MonoGame.Framework">
  <HintPath>$(MSBuildExtensionsPath)\..\MonoGame\v3.0\Assemblies\Windows\MonoGame.Framework.dll</HintPath>
</Reference>

Which means they assume that MonoGame is installed on the machine.

Should we make part of the samples build process install the latest version of MonoGame? Or should we alter the .csproj to use something more complex like:

<PropertyGroup>
  <MonoGameAssembliesPath Condition=" '$(MonoGameAssembliesPath)' == '' ">$(MSBuildExtensionsPath)\..\MonoGame\v3.0\Assemblies</Configuration>
</PropertyGroup>
<Reference Include="MonoGame.Framework">
   <HintPath>$(MonoGameAssembliesPath)\Windows\MonoGame.Framework.dll</HintPath>
</Reference>

This allows us to overload the location of the MonoGame assemblies from the build server by pre-defining the value of $MonoGameAssembliesPath.

Thoughts?

@tomspilman
Copy link
Member Author

@KonajuGames @DDReaper ??

@SimonDarksideJ
Copy link
Collaborator

Certainly sounds like a plan, but only do with with confirmed working projects in the repository. Obviously only the Platformer sample at present fits that bill fully.

What I would recommend is to automate the NuGet package creation and use that and the NuGet package restore features of NuGet to test the samples rather than build directly against source.

Nothing wrong with doing against source but most devs I speak to use the NuGet's first and source second

@tomspilman
Copy link
Member Author

What I would recommend is to automate the NuGet package creation

I see the NuGet issue is something separate. I know we haven't gotten to it... I will make the effort to solve that soon as I know some people love that method of distribution.

Still it is another method to solve this issue. TeamCity even has some good NuGet functionality built in, so we could depend on it and not the artifact sharing features if we needed to.

rather than build directly against source.

The TeamCity build server makes it easy to share the latest MonoGame build artifacts. The samples build process would simply use those and not need to rebuild anything.

@tomspilman
Copy link
Member Author

Added an issue specifically about NuGet automation in MonoGame/MonoGame#2843.

@SimonDarksideJ
Copy link
Collaborator

Was thinking about this in the last PR.
Might be worth dropping NuGet in the samples for automated building, trick then is where to get the runtime DLL's for the samples.
Thoughts @tomspilman ?

Fine for the automated process but how would devs put the DLL's in for local running (although they could manually use the NuGet's of course)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants