We Keep Coding

Retrieving Records and Saving to a Database in a single C# Web Service

Hi i am trying to combine a C# webservice in azure with a get and a post at the same time, the idea is to get the details of a CD by the uniqueCDcode and the webservice outputs just the json information AND the uniqueCDcode needs to be stored in a different table CDClicked to i get a list of all the clickedCD's so i am able to take the last 50 as for trending etc. but don't really seem to get it to work. This is what i have so far
//// WS# 00002 GET THE ALBUM DETAILS
[Route("api/Music/Album/{uniqueCDcode}")]
public HttpResponseMessage GetAlbum(int uniqueCDcode)
{
return Request.CreateResponse(HttpStatusCode.OK,
new { AlbumMusic = db.Music
.Where(am => am.uniqueCDcode == uniqueCDcode);
db.CDClicked.Add(uniqueCDcode);
}

You need to retrieve your record/do the save, then return the response. The Add() method call to dbContext (second part) isn't working because the return statement is returning a value first, and then stopping the execution of your service, so it never gets to the second part. Your logic needs to be done before the return statement.
For example:
[Route("api/Music/Album/{uniqueCDcode}")]
public HttpResponseMessage GetAlbum(int uniqueCDcode)
{
db.CDClicked.Add(uniqueCDcode);
return Request.CreateResponse(HttpStatusCode.OK,
new { AlbumMusic = db.Music
.Where(am => am.uniqueCDcode == uniqueCDcode )});
}
You also had some formatting issues in the code. Your braces and parens didn't match up (at least in the code that you pasted into SO.) I corrected in my answer below.
Note: I can't test the code at the moment due to hurricane-related issues, but this is the general concept to get you going again.

Send logic over Http

I'm trying to send a class that contains a Function over http.
Can this be accomplished?
Its supposed to work like this:
1) Client contacts Web.API.
2) Web.API returns class with the Function
3) Client executes Function.
Class will look a bit like this :
public class UploadTicket
{
public string url { get; set; }
public List<Tuple<string, string>> Headers { get; set; }
public Func<string> SpecialFunction { get; set; }
}
I need this function to alter the uploadurl by appending an ID every time a package is sent - but only if it's to certain dataproviders, and in other cases uploadurls must be modified in other ways. I need to do it this way, so i can keep the client side code as general as possible.

Sounds a little goofy but yeah you can, on the condition that you send source to the client and not some pre-compiled version (otherwise it'd really be a gaping security hole). Just use the C# runtime compiler. But it implies the client is C#, that's why it sounds goofy.
This is actually a common pattern everybody uses every day. Think of the web browser that hits a web server and gets a page with javascript in it. The same thing happens. The browser compiles the JS and executes it, even though the source was produced remotely.

How to display errors with ASP.NET Core

I have a fairly simple website that I am playing with using ASP.NET Core. I am running the application from the command line and the website is returning static files but I keep getting 500 errors when I attempt to make a request that should get handled by MVC. How do I see what the error is? Whether the error is displayed to the browser or logged to the console doesn't matter I just want a way to see what the error is.

Add the error page middleware as shown here:
app.UseDeveloperExceptionPage();

Update for beta8:
In beta8 Microsoft changed the name to UseDeveloperExceptionPage. So if you want to use the ErrorPage, call:
app.UseDeveloperExceptionPage();
Here is the link to the related Github issue.
The ErrorPageOptions are the same as in beta6/7.
You can use
app.UseErrorPage(ErrorPageOptions.ShowAll)
until beta5 of Asp.Net Mvc.
As of beta6, ErrorPageOptions.ShowAll has been removed. You can now use the version without parameters
app.UseErrorPage();
or create an ErrorPageOptions object and specify how many lines around the error you want to display by setting SourceCodeLineCount.
app.UseErrorPage(new ErrorPageOptions() {SourceCodeLineCount = 100});
Additional Information
They removed multiple properties of ErrorPageOptions in this commit.
Before:
public class ErrorPageOptions
{
private bool _defaultVisibility;
private bool? _showExceptionDetails;
private bool? _showSourceCode;
private bool? _showQuery;
private bool? _showCookies;
private bool? _showHeaders;
private bool? _showEnvironment;
...
}
After:
public class ErrorPageOptions
{
public int SourceCodeLineCount { get; set; }
public IFileProvider FileProvider { get; set; }
...
}
So now you can only set how many lines of source code are printed.

If you don't care that your error details would be exposed to the world, you can enable the error details, right in the browser without any code changes. (This was only tested in IIS 8.5):
In IIS Manager, in the left Connections section, left-click select your Site.
In the right side Feature View open Error Pages.
On the far right Actions section, click on Edit Feature Settings
In the Error Responses, select the 2nd, Detailed errors, option then Ok (or if you are worried about exposing stuff to the world, start with the 3rd option, if you can open a local browser... ie, localhost:...)
This should be enough for you to be able to see the exact error... Important: If you had to use the middle Detailed errors option, be sure to turn it off once you debug the problem. This can give a hacker all he needs to break into your server.

If it is not important to expose the detail of the error to the world, then you can activate detailed error page in web.config.
Just add <customErrors mode="Off"/> in the <configuration> / <system.web> of your web.config file located in root folder of your web site.
For more detailed explanation:
How to Use Web.Config customErrors for ASP.NET
This has the advantage that you don't have to redeploy your site

How can I get the URL of the current page from within a C# App_Code class?

I have a logging class that, well, logs things. I would like to add the ability to automatically have the current page be logged with the messages.
Is there a way to get the information I'm looking for?
Thanks,

From your class you can use the HttpContext.Current property (in System.Web.dll). From there, you can create a chain of properties:
Request
Url and RawUrl
The underlying object is a Page object, so if you cast it to that, then use any object you would normally use from within a Page object, such as the Request property.

It's brittle and hard to test but you can use System.Web.HttpContext.Current which will give you a Request property which in turn has the RawUrl property.

public static class MyClass
{
public static string GetURL()
{
HttpRequest request = HttpContext.Current.Request;
string url = request.Url.ToString();
return url;
}
}
I tried to break it down a little :)

In the past I've also rolled my own logging classes and used Console.Writeln() but really there are a number of good logging options that already exist so why go there? I use NLog pretty much everywhere; it is extremely flexible with various log output destinations including console and file, lots of log format options, and is trivial to set up with versions targeting the various .net frameworks including compact. Running the installer will add NLog config file options to the Visual Studio Add New Item dialog. Using in your code is simple:
// declare in your class
private static Logger logger = LogManager.GetCurrentClassLogger();
...
// use in your code
logger.Debug(() => string.Format("Url: {0}", HttpContext.Current.Request.Url));

ASP.NET MVC singleton or static class to pass around data?

I'm creating a controller that will serve the combined/minified versions of my JavaScript and CSS. I need to somewhere along the line define which scripts/styles to be loaded.
When a request is made, for example for style.css?VersionNumberHere, it will check if the combined/minified data is already in the HttpContext.Cache, if so spit it out. Otherwise, I need to look up the definition that makes up style.css.
I created a Script/StyleBuilder (that inherits from ContentBuilder) that will store all the paths that need to be combined and then squished (so this would be the definition of style.css).
Where should I be storing these references to the "builders"? Should they be in a static class or a singleton that implements an interface so that it can be tested?
Here's the interface that the abstract class ContentBuilder implements (you can easily imagine the implementation):
public interface IContentBuilder : IEnumerable<string>
{
string Name { get; }
int Count { get; }
string[] ValidExtensions { get; }
void Add(string path);
bool ValidatePath(string path);
string GetHtmlReference(); // Spits out <script>, or <link> depending on implementation.
string Build(); // Minifies, combines etc.
}
And here is ideally what I'd like to be able to do with these:
ContentBuilderContainer.Current.Add("main.js", c => new ScriptBuilder()
{
"/path/to/test.js",
"/path/to/test2.js",
"/path/to/test3.js"
});
ContentBuilderContainer.Current.Add("style.css", c => new StyleBuilder()
{
"/path/to/style.css",
"/path/to/test.less"
});
Then to output all the HTML for all registered IContentBuilder:
ContentBuilder.Container.Current.BuildHtml();

Maybe you should check out SquishIt. Some more info on it in this blog post. We use it in production.

Attach caching attributes to your controller actions and cache by parameter like this:
[OutputCache(Duration = 7200, Location = OutputCacheLocation.Client, VaryByParam = "jsPath;ServerHost")]
[CompressFilter]
// Minifies, compresses JavaScript files and replaces tildas "~" with input serverHost address
// (for correct rewrite of paths inside JS files) and stores the response in client (browser) cache for a day
[ActionName("tildajs")]
public virtual JavaScriptResult ResolveTildasJavaScript(string jsPath, string serverHost)
...

I made the following interface:
public interface IContentBuilderContainer
{
int Count { get; }
bool Add(string name, Func<IContentBuilder> contentBuilder);
string RenderHtml();
}
And then in the implmentation of ContentBuilderContainer:
public class ContentBuilderContainer : IContentBuilderContainer
{
// Other members removed for simplicity.
#region Static Properties
/// <summary>
/// Gets or sets the current content builder container.
/// </summary>
public static IContentBuilderContainer Current
{
get;
set;
}
#endregion
#region Static Constructors
static ContentBuilderContainer()
{
ContentBuilderContainer.Current = new ContentBuilderContainer();
}
#endregion
}
This way there's a single ContentBuilderContainer living at one time.

I helped write some code that did this recently. Here's a high level overview of the solution that was implemented. Hopefully it will give you some good ideas.
Configuration: We created custom configuration elements that define a key and their a corresponding list of directories. So the key JS is linked to our /Content/Scripts folder, and CSS is linked to our /Content/Styles folder. I have seen other solutions where the configuration allowed for individual files to be listed.
Controller: The controller was set up to receive requests something along the lines of /Content/Get/JS and /Content/Get/CSS. The controller uses the configuration key and client request headers to come up with a cache key that identifies the content we want to serve: JS-MSIE-ZIP, CSS-FFX, etc. The controller then checks our cache service. If the content is not there, it gets concatenated, minified, compressed, cached and then served. Handy fallout is that the content is compressed before going into the cache instead of every time it's served.
View: In the View, the links are set up like this:
<link href="<%: Url.Action("Get", "Content", new { key = "CSS" }) %>" rel="stylesheet" type="text/css" />
Cache Service: We're using an existing cache service we have that just wraps the application cache. At some point we'll probably move that to Velocity or something similar. If the amount of CSS and JS we cache keeps growing, we'll probably change the format of the key to a proper filename and move the content to the file system. But, memory's pretty cheap, we'll see what happens.
Reasoning: (if it matters)
We did this in order to keep the JavaScript for different features in separate files in source control without having to link to all of the files individually in the HTML. Because we configure our content by directory and not individual files, we can also run a full minification during production builds to speed up the whole run time process somewhat. Yet we still get the benefit of determining which content to serve based on the client browser, and cached compressed versions.
In development, the system can be set up with a quick configuration change so that every request rebuilds the JS. The files are concatenated with file names injected in comments for easy searching, but the content is not minified and nothing is cached anywhere. This allows us to change, test and debug the JS without recompiling the application.
Couldn't quite find all these features in a package out there so we spent a couple of days and built it. Admittedly some features were just for fun, but that's why we like doing what we do. =)