August 12th, 2010
I spent the last few weeks working on a Rails project. Although there was a lot to learn, I feel as though I have a decent understanding of Ruby and Rails at this point. I am by no means an expert, but I can do the basics without googling. I figured I would document my thoughts on what every developer should learn from the Rails framework.
- Gems - Having a package manager to to handle dependencies rocks. In contrast, every single .NET library includes all its dependencies because there is no package manager to make it easy. Hopefully nu can start to fill this void.
- Generators - Generators save your team time because they aren’t spending time typing out common patterns in a project. Many frameworks like .NET have code generation, but the barrier to entry seems high. Maybe I just haven’t spent enough time out it, but in a few years of programming .NET, I haven’t generated a single class.
- Conventions - Developers shouldn’t have to ask, Where should this class go?. Conventions should define that, otherwise teams are forced to define their own (which usually leads to a lack thereof except in experienced teams).
- Database management – In nearly every app I have worked with, schema gen, creation, migration, and testing integration are a pain point. Many libraries like NHibernate have the capability of doing all these tasks, but there is no instruction manual for setting it up. Therefore, most projects don’t manage their database very well.
- The build, the build, the build – Dependencies, database migrations, multiple environments, testing…need I say more? Having an out of the box build that does more than plain old compilation is a must in any solid framework. Like everything else, tools like MSBuild can do all this but the team is forced to start from scratch.
Where does Rails succeed where many applications and frameworks like ASP.NET MVC fail? Rails succeeds at allowing developers to focus on the application, not the plumbing.
Uncategorized | 
3 Comments »
July 28th, 2010
Package management has been on my mind for months as one of the greatest short comings in .NET. If you spend two hours using Ruby and gems, you realize how much easier it is than finding the appropriate .NET assemblies to use. It also promotes using open source libraries, instead of re-inventing the wheel.
nu aims to provide this for .NET.
I checked it out tonight. Here is my experience.
First step is to install it, and ruby is the only pre-req. The following commands show how to install and use it.
> gem install nu
> mkdir test
> cd test
> nu install nunit
> nu install nhibernate
Wow, that was easy. nu downloaded nhibernate and nunit, and placed them in the lib folder (including all of NHibernate’s dependencies). By the way, it literally took less than 30s for me to do this.
So what do I think?
- It is an easy and fast delivery tool.
- Using Ruby isn’t that big of a deal, but I think that is my opinion, not the community opinion.
- It is new, so it has a ways to go in terms of functionality in discovery. I can’t hate because at least they have released something and I have just dreamed about releasing something.
- Build integration (and probably Visual Studio) is going to be key. And by build, I don’t just mean NAnt and UppercuT, but MSbuild too.
- The biggest hurdle is building a “gem” community in .NET. For some reason, creating a .NET gem seems kind of awkward (even though it isn’t that hard).
Uncategorized | 1 Comment »
July 14th, 2010
MSBuild is a very powerful build tool. Unfortunately, in my experience, I have seen it utilized very little. Instead, developers rely entirely on Visual Studio for the build, which is a mistake. I think there are a couple reasons for this:
- Modifying the build feels like you are mucking in the internals of Visual Studio
- There is no convention based approaches for how to handle custom bulid targets
Now, you could go the way of NAnt, and have complete independence from Visual Studio. I think this is a mistake as well. Visual Studio, while being a royal pain much of the time, is still a very very very powerful tool. I believe we should embrace it, while using MSBuild plus conventions to achieve ultimate flexibility.
The proposal
It’s actually quite simple. Each assembly/project already has its own *.csproj file, which is in essence a partial MSBuild file. The problem is editing it is weird and scary at times, because it is auto-generated by Visual Studio.
Just add the following to any or all your csproj files.
<Project>
... All the visual studio muck ...
<Import Project="$(MSBuildProjectName).targets" Condition="Exists('$(MSBuildProjectName).targets')" />
</Project>Then add a file with that name. If your projects name is Reference.Web, then add a file named Reference.Web.targets and include it in the project. The content could contain something like the following.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<Files Include="$(SolutionDir)\configuration\$(Configuration)\$(AssemblyName).*.config" />
<Files Include="$(SolutionDir)\configuration\$(Configuration)\Common.*"/>
</ItemGroup>
<Target Name="InstallConfiguration">
<Copy SourceFiles="@(Files)" DestinationFolder="$(OutputPath)" />
</Target>
<!-- Override the AfterBuild target -->
<Target Name="AfterBuild" DependsOnTargets="InstallConfiguration" />
</Project>Now you have a build file separate from the project that is really easy setup and use, straight for Visual Studio.
The only gotcha is Visual Studio won’t automatically notice the build file changes, so you still have to relad the assembly after you make a build file change.
UPDATE – More robust Import statement
Via @sayedihashimi
Even better would be a conditional import, and you should use the MSBuildProjectName property instead of AssemblyName.
Uncategorized | No Comments »
