Hi

1. Pulled everything out, compiled, unresolved references.
2. got references thorugh NuGet, but it loads EntLib 5.0 ot 3.0 like used in Contrib
3. some APIs changed (Microsoft.Practices.ObjectBuilder) and broken

So, NuGet cannot be that easily used with Contrib package

Suggestion: to keep assemblies in References\ project like CompositeC1 in Bin\ and add them into version control?!

regards

mel

Can you describe your steps more in details? I've never experienced any of these issues you mention, and there is no dependencies on the NuGet package so it should not behave like this.

Good Morning

1. using TortoiseHG I cloned source from: https://hg.codeplex.com/compositec1contrib
2. opened up CompositeC1Contrib.sln most of projects with missing references to Composite, Composite.Workflows, EntLib
3. fixed Composite as project references
4. although in Composite project there are dlls for EntLib I decided to go for NuGet
   1. right click on References +/ Manage packages with NuGet +/ search online for Enterprise Library +/ Install
      this should be the same as Install-Package EnterpriseLibrary
   2. did not check versions - Mea Culpa
   3. NuGet gets latest EntLib version -5 (to be more precise 5.05 I think)
5. added all Contrib projects to CompositeC1 Web Site solution as existing projects and fixed all dependencies as references to projects
6. started website
7. assebmly loading excpetions - stating that Microsoft.Enterprise.Library.*.dll version 3.0.0 could not be loaded...
8. deleted all references to EntLb (5.0 by NuGet) and 
9. added required EtLib dlls v.3.0 from CompositeC1 solution Bin\ folder (checkout done by TortoiseSVN)
10. this fixed errors

So suggestion

1. adding to CompositeC1Contrib.sln
   1. either folder with dlls (like CompositeC1.sln) with all dlls
   2. or (more complicated) project as placeholder with libs and stuff to reference

this way it is possible to add refs relatively to solution and projects - maybe editing refs by hand

OK. Now I see You have everyhing in project Hints to References folder!!! Reletive paths, but dlls are not in SCC - at least I did not get them by clone

    <Reference Include="Composite">
      <HintPath>..\References\Composite.dll</HintPath>
    </Reference>
    <Reference Include="Composite.Workflows">
      <HintPath>..\References\Composite.Workflows.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.Practices.EnterpriseLibrary.Common, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\References\Microsoft.Practices.EnterpriseLibrary.Common.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.Practices.EnterpriseLibrary.Validation">
      <HintPath>..\References\Microsoft.Practices.EnterpriseLibrary.Validation.dll</HintPath>
    </Reference>

Maybe checking what is Added/Commited to BitBucket?

I just browsed - only 7z.exe 64bit

regards

mel

Its true that there are some implicit dependencies on the Composite C1 binaries, but i don't see the argument of including them in VCS, when its easy downloadable from http://compositec1.codeplex.com/releases/view/86614. It just makes the download size bigger, and introduces more files that needs to be updated/maintained.

To put it on the edge, i don't include VS or .Net framework in VCS either, i expect people interested in working with it to have these prerequisites in place.

The same way, i expect people to have the binaries for Composite C1 themselves. Same goes for WebPages binaries if you want to build RazorFunctions, the Facebook SDK if you want to build the Facebook package etc.

OK. Including dlls in VCS was just suggestion to discuss it. It is true I can download it and I did, as I did for CompositeC1. But when I see binaries included in VCS and projects for me there is warning "we use this - if  you don't - it is your problem" - then I would not go for NuGet installation. Usually if there is no docs, when I see unresolved refs i look in solution if there are some binaries, then I go to download them

To put it on the other edge - why then 7z.exe? Build/packaging would fail - one would get 7z, Smarter people read .csproj and get everything in place before first build...

It is contradictory that main solution includes binaries and contrib not (forget 7z) - a little bit more uniform project/solution organization would be helpful.

I didn't find docs where it is stated: use only EntLib 3.0 (not 5.0 with nuget),

So this was just suggestion to make structure better organized/structured and more uniform, so that other people wiling to help lose less time.

cheers

i'm glad you're willing to discuss this, and surely i'm open for suggestions.

I get the impression that you like NuGet, which is good, NuGet is awesome. Would it help to release the C1 binaries as a separate NuGet package and reference that in the solution? By principle i'm reluctant to include binary files that are not mine, but can be obtained from 3rd parties. So i would vote for either a Readme-file with how to setup up the build environment, or doing some NuGet tweaking.

Regards to the 7z, you're right and its a mistake. Actually i'm planning to move the whole package-creation to a TeamCity server so its not a buildstep in VS since it just causes problems. And by having a dedicated Package Server as well, i also get rid of having the binary zip-files in VCS, and TeamCity supports making NuGet packages directly so its a win-win to get these processes more streamlined.

Also remember, that so far you're the first one starting a discussion on this By being the only developer, you don't really think about these things of having Readme files and such. And especially since no one seems to have had the interest in building from source i just decided to release the finished packages as zip-files and didn't think so much about the build environment.

I hope that you haven't been scared away and want to start contributing, it will make you the first one!

I would vote for readme with only statement that Enterprise Library 5.0 will break build-

Packaging in Nuget would take You more time and I bet it is precious for You.

7z is not mistake, but just misleading (BTW did you see my shell script update in another thread that checks for 32bit system and uses 7z for 32). It works ok on 2 of my pcs.

TeamCity - uff something new I have to learn...

I'll help You as I work on my web projects based on CompositeC1 i have several ideas and more and more potential coding buddies...

I'm preparing my environment and what I have done for contribs and no I'm not scared - don't worry. And I know I'm not the only one I saw Your presenataition at hackathon and You already had one commit!

What else do I need for contributing?

1. BitBucket account - I am about to get it
   1. write access?
2. styleguides (rulez and recommendations)
3. ideas (pleny)

cheers

Regarding to the Enterprise Library, its a general C1 issue.... lets say you have a project that uses EntLib 5.0 and drop that into a C1 site, then things will break as well.

About not having 3rd party binaries i VCS, then 7z shouldn't be there as well. It used to not be there, but then the build failed, and for people not interested in making C1 Packages out of the projects, then it makes sense to have it as a opt-in and not requirement. Personally for myself, i never install C1 packages but uses either NuGet or just copies files manually.

TeamCity is cool for automatic build and packaging http://www.jetbrains.com/teamcity/. I have it running on customers websites, so changes i do on my local machine and commit is automatically build, tested, and deployed to the live website.

The way DVCS works, you would create an account on BitBucket and just fork my https://bitbucket.org/burningice/compositec1contrib repro. Then you work, make changes etc. and when you have something to share you would ask me to pull it from you (a pull request). The same way, when there is changes to https://bitbucket.org/burningice/compositec1contrib, you would periodically make a pull to your repro to keep them in sync.

This is the safest and easiest way to be several developers on the same codebase. Then we can look at sharing write-access across repros later :)

About styleguides, i guess you can get a feel by looking around;

• All assemblies and Namespaces starts with CompositeC1Contrib
• There is a Core assembly for shared code between projects
• I try to use as much of the standard asp.net framework whenever i can (caching, sitemap, HttpApplication, Routing, Modules and Handlers)
• If a project needs datatypes its defined as static types
• Trying to stick to convention over configuration when possible
• If functions needs to be added to C1, filebased functions (cshtml or UserControl) or a dedicated function provider is preferred over Inline C#, method based or XSLT functions.
• If a project needs its own tree in the Console, a dedicated Element provider is preferred over TreeDefintions
• Content and config needed to be added to the site together with the project goes to
  • Config: /Package/config
  • Content: /Package/content
• Content added to the C1 Console goes to /Composite/InstalledPackages/<project name>