Open danielmarbach opened 10 years ago
I would suggest doing a nuget package that only contains this storage provider. You can setup dependencies in the nuget package that will allow it to automatically get all the dependencies. Here is an example nuspec file:
<?xml version="1.0"?>
Once you have this nuspec file created you could write a batch file (I usually do this in build scripts, which is why this example contains build variables) that does something like this:
IF NOT EXIST "$(TargetDir)nuget" mkdir "$(TargetDir)nuget"
IF NOT EXIST "$(TargetDir)nuget\lib" mkdir "$(TargetDir)nuget\lib"
IF NOT EXIST "$(TargetDir)nuget\lib\net45" mkdir "$(TargetDir)nuget\lib\net45"
xcopy /y "$(TargetDir)*.nuspec" "$(TargetDir)nuget"
xcopy /y "$(TargetPath)" "$(TargetDir)nuget\lib\net45"
cd "$(TargetDir)nuget"
IF EXIST ".nupkg" del .nupkg
nuget pack
if $(ConfigurationName) == Release nuget push *.nupkg -s http://nuget.cameronvetter.local/
The last line would need to get modified to aim at the nuget repo, that example is aiming at my local repo. The advantage of using dependencies is that your package will continue to work as new ravendb versions come out without any changes, assuming they don’t do anything that breaks compatibility.
Hopefully those example files save you a little bit of time…
Cameron Vetter
From: danielmarbach [mailto:notifications@github.com] Sent: Monday, June 16, 2014 4:25 PM To: danielmarbach/orleans.storageprovider.ravendb Subject: [orleans.storageprovider.ravendb] Nuget package/s (#3)
What would be the best approach for the nuget package/s? Currently there is one assembly supporting full ravendb, embedded and in-memory. Which requires the client code to reference a lot of nugets from RavenDB. I can either do one big nuget package with everything contained or for each supported mode one package. What is your take?
— Reply to this email directly or view it on GitHub https://github.com/danielmarbach/orleans.storageprovider.ravendb/issues/3 . https://github.com/notifications/beacon/7763701__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxODU3MzA4NSwiZGF0YSI6eyJpZCI6MzQ3OTAyODZ9fQ==--c9109cac73edfaa88977d28137668d2e58052753.gif
Cameron, thanks for the sample. There is a missunderstanding here. I have written several nuspecs in the past and I'm aware how it works and all the conventions it follows. My discussion was in another direction:
The provider has server mode for production which needs special nuget packages. Then there is the emedded mode for limited persistent testing of a few grains which needs the raven.embedded nuget as a dependency. One could argue that for the server mode you don't really want to download this dependency. But as with the current architecture both are in the same assembly they would end up in the same nuget file. So my question was: is this ok for you or should I split out into
provider.core Provider.server Provider.embedded ...
Am 17.06.2014 um 05:37 schrieb CameronVetter notifications@github.com:
I would suggest doing a nuget package that only contains this storage provider. You can setup dependencies in the nuget package that will allow it to automatically get all the dependencies. Here is an example nuspec file:
<?xml version="1.0"?>
OrleansRavenDB 1.0.0 Daniel Marbach false Orleans Storage Provider for Raven DB Orleans RavenDB Once you have this nuspec file created you could write a batch file (I usually do this in build scripts, which is why this example contains build variables) that does something like this:
IF NOT EXIST "$(TargetDir)nuget" mkdir "$(TargetDir)nuget"
IF NOT EXIST "$(TargetDir)nuget\lib" mkdir "$(TargetDir)nuget\lib"
IF NOT EXIST "$(TargetDir)nuget\lib\net45" mkdir "$(TargetDir)nuget\lib\net45"
xcopy /y "$(TargetDir)*.nuspec" "$(TargetDir)nuget"
xcopy /y "$(TargetPath)" "$(TargetDir)nuget\lib\net45"
cd "$(TargetDir)nuget"
IF EXIST ".nupkg" del .nupkg
nuget pack
if $(ConfigurationName) == Release nuget push *.nupkg -s http://nuget.cameronvetter.local/
The last line would need to get modified to aim at the nuget repo, that example is aiming at my local repo. The advantage of using dependencies is that your package will continue to work as new ravendb versions come out without any changes, assuming they don’t do anything that breaks compatibility.
Hopefully those example files save you a little bit of time…
Cameron Vetter
From: danielmarbach [mailto:notifications@github.com] Sent: Monday, June 16, 2014 4:25 PM To: danielmarbach/orleans.storageprovider.ravendb Subject: [orleans.storageprovider.ravendb] Nuget package/s (#3)
What would be the best approach for the nuget package/s? Currently there is one assembly supporting full ravendb, embedded and in-memory. Which requires the client code to reference a lot of nugets from RavenDB. I can either do one big nuget package with everything contained or for each supported mode one package. What is your take?
— Reply to this email directly or view it on GitHub https://github.com/danielmarbach/orleans.storageprovider.ravendb/issues/3 . https://github.com/notifications/beacon/7763701__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxODU3MzA4NSwiZGF0YSI6eyJpZCI6MzQ3OTAyODZ9fQ==--c9109cac73edfaa88977d28137668d2e58052753.gif — Reply to this email directly or view it on GitHub.
What would be the best approach for the nuget package/s? Currently there is one assembly supporting full ravendb, embedded and in-memory. Which requires the client code to reference a lot of nugets from RavenDB. I can either do one big nuget package with everything contained or for each supported mode one package. What is your take?