search

nsabiyera / Oak

Frictionless development for ASP.NET MVC single page web apps. Prototypical and dynamic capabilities brought to C#.
http://amirrajan.github.com/Oak
MIT License
6 stars 7 forks source link

Installing Cambium from NuGet does not build #29

Closed khalidabuhakmeh closed 10 years ago

khalidabuhakmeh commented 10 years ago

I get the exception message of

The type or namespace name 'ConnectionStringSettings' could not be found (are you missing a using directive or an assembly reference?)

The NuGet package might be missing a dependency that contains this class, but I'm not sure because I've never even heard of it.

I also find it strange that the package is not a dll, but instead a bunch of files. I am immediately weary of a managing that many files (14) while still having to maintain my set of files. A single assembly is always the most preferable way to consume a NuGet package.

khalidabuhakmeh commented 10 years ago

It is under System.Configuration. Probably should be added as a dependency of the package :)

amirrajan commented 10 years ago

It is under System.Configuration. Probably should be added as a dependency of the package :)

This has been fixed in 1.5.3. I also added a connection string constructor overload for DynamicDb

I also find it strange that the package is not a dll, but instead a bunch of files. I am immediately weary of a managing that many files (14) while still having to maintain my set of files. A single assembly is always the most preferable way to consume a NuGet package.

This is a bit trickier. Here's why:

Whenever an anonymous type is created like the following:

var something = new { Name = "Bob Loblaw" }

An internal class is created by C#. Which means that an external dll can't see any types that are generated.

So if I were to create a seperate dll, the developer would be forced to put the following in AssemblyInfo.cs

[assembly: InternalsVisibleTo("Oak")]

Infact, just to get a reasonable test story for even situations like this:

return Json(new { AValue = "hello" }); //json payload returned from a controller

you have to make your MVC project visible to your test project... which is what I do in the Oak related warmup templates:

https://github.com/amirrajan/Loam/blob/master/__NAME__/Properties/AssemblyInfo.cs#L16

This is also why Massive is just a cs file (as opposed to a separate dll).

This blog entry goes into some detail with regards to this issue:

http://weblogs.asp.net/gunnarpeipman/archive/2010/07/24/asp-net-mvc-using-dynamic-type-to-test-controller-actions-returning-jsonresult.aspx

So it's an issue of pick your poison.