I'm using the following code to query an excel file in LinqToExcel:
var excelFile = new LinqToExcel.ExcelQueryFactory(#"\"+txtFileName.Text.Replace(#"\\",#"\"));
var properties = from p in excelFile.Worksheet<Property>()
where AssessmentID != null
select p;
foreach (var autoP in properties)
doSomething();
When I look at the runtime debugger, I see an "InvalidCastException" while looking at the "Results View" of the properties variable. So, I'm assuming that there's something funky going on with my class definition. I'm also assuming that I don't need to map all members of the class to the excel file, but rather only the ones I see fit.
So, Here's the class definition as well:
public class Property
{
[DataMember]
public int? Year { get; set; }
[DataMember]
public string ChangeReason { get; set; }
[DataMember]
public string AssessmentID { get; set; }
[DataMember]
public string CallBackNotes { get; set; }
[DataMember]
public string InspectionNotes { get; set; }
[DataMember]
public string Notes { get; set; }
[DataMember]
public bool Authorization { get; set; }
[DataMember]
public string ChargeStatus { get; set; }
[DataMember]
public string LegalLandDesc { get; set; }
[DataMember]
public string Address { get; set; }
}
Here's a link to the source code for linqToExcel on GitHub:LinqToExcel
The generics are more complicated than I've seen, and are something that I (apparently) need to brush up on.
Is there something glaring that I'm missing that would cause this issue? Any ideas as to where to look or what to do to resolve these errors?
The where clause of the query is what was causing the error. It was referencing the null keyword which was not applicable in the context.
I changed it to:
where !String.IsNullOrEmpty(p.AssessmentID)
This solved my issue.
Note to self: When inheriting code from others, check the basics first!
Related
I have the following main class:
public class ResearchOutcome
{
public ResearchOutcomeCategory ResearchOutcomeCategory { get; set; }
public string? UniqueIdentifier { get; set; }
}
And the category class is:
public class ResearchOutcomeCategory
{
public int Id { get; set; }
public string Name { get; set; }
public string? Description { get; set; }
}
The View models for above classes are:
public class ResearchOutcomeDetailVm : IMapFrom<ResearchOutcome>
{
public int Id { get; set; }
public virtual ResearchOutcomeCategoryDetailVm ResearchOutcomeCategory { get; set; }
}
public class ResearchOutcomeCategoryDetailVm : IMapFrom<ResearchOutcomeCategory>
{
public int Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
}
Now, I have used the following mapping profile:
// First this one
profile.CreateMap<ResearchOutcomeCategory, ResearchOutcomeCategoryDetailVm>();
profile.CreateMap<ResearchOutcome, ResearchOutcomeDetailVm>();
//Then I tried this one
profile.CreateMap<ResearchOutcome, ResearchOutcomeDetailVm>()
.ForMember(o => o.ResearchOutcomeCategory,
cat => cat.MapFrom( o => o.ResearchOutcomeCategory));
But the ResearchOutcomeCategory is always null. Any help would be appreciated.
After digging more, I identified that I was not "Including" the relevant item in the query, hence, the view model was always empty. Pretty dumb on my part :D
Regarding the mapping, if the properties (even complex ones) have the same names, then the mapper will map them automatically. So simply this line worked
profile.CreateMap<ResearchOutcomeCategory, ResearchOutcomeCategoryDetailVm>();
Hope it helps someone
I'm having an issue with the ServiceStack implementation of Swagger with regards to the documentation of generic-typed response objects. Strongly-typed response objects are correctly documented and displayed, however once a generic-typed object is used as a response, the documentation is inaccurate and misleading.
Request DTO
[Route("/users/{UserId}", "GET", Summary = "Get a specific User Profile")]
public class GetUser : IReturn<ServiceResponse<UserProfile>>
{
[ApiMember(Description = "User Id", ParameterType = "path", IsRequired = true)]
public int UserId { get; set; }
}
Response DTO
public class ServiceResponse<T> : IServiceResponse<T>
{
public IList<string> Errors { get; set; }
public bool Successful { get; set; }
public string Message { get; set; }
public string StackTrace { get; set; }
public T Data { get; set; }
public ServiceResponse()
{
Errors = new List<string>();
}
}
Response DTO Type
public class UserProfile : RavenDocument
{
public UserProfile()
{
Races = new List<UserRace>();
Workouts = new List<Workout>();
}
public string FirstName { get; set; }
public string LastName { get; set; }
public string DisplayName { get; set; }
public DateTime? BirthDate { get; set; }
public Gender? Gender { get; set; }
public string UltracartPassword { get; set; }
public string UltracartCartId { get; set; }
[UniqueConstraint]
public string Email { get; set; }
public string ImageUrl { get; set; }
public FacebookUserInfo FacebookData { get; set; }
public GoogleUserInfo GoogleData { get; set; }
public DateTime CreatedOn { get; set; }
public DateTime? LastUpdated { get; set; }
public UserAddress ShippingAddress { get; set; }
public UserAddress BillingAddress { get; set; }
public IList<UserRace> Races { get; set; }
public IList<Workout> Workouts { get; set; }
}
The examples are pretty straight forward. Nothing really hacky or clever going on, however this is the sample documentation I get from Swagger out of the box:
As you can see, the generic type isn't documented correctly and some other type is used instead. As I am using this same ServiceResponse wrapper for all my responses, this is happening across the board.
As you have found, the ServiceStack swagger plugin does not currently attempt to handle generic types cleanly. A simple alternative that should work better is to make concrete subclasses of the generic types. e.g.:
public class UserProfileResponse : ServiceResponse<UserProfile> { ... }
public class GetUser : IReturn<UserProfileResponse> ...
This should be handled properly by Swagger.
I've found generic types aren't always a great fit for ServiceStack DTOs. You'll find many discussions (for example here, here and here) on StackOverflow that discuss this, and the reasons why concrete types and generally avoiding inheritance is a good idea for ServiceStack DTOs.
It takes effort to overcome the temptation to apply the DRY principle to request/respone DTOs. The way I think about it is that generics and inheritance are language features that facilitate implementation of algorithms in generic, reusable ways, where the generic method or base class doesn't need to know about the details of the concrete type. While DTOs may superficially have common structures that look like opportunities for inheritance or generics, in this case the implementation and semantics of each DTO is different for each concrete usage, so the details of each request/response message deserve to be defined explicitly.
I'm having an issue with my ServiceStack w/ Swagger implementation regarding documenting required/optional properties. Developers implementing clients that consume my services love the Swagger documentation, however they don't know which properties are required vs. optional--aside from getting a 400 response on each attempt to get a valid request through.
Take the following example:
public class UserProfile
{
public string FirstName { get; set; }
public string LastName { get; set; }
public UserAddress Address { get; set; }
}
public class UserAddress
{
public string AddressLine1 { get; set; }
public string AddressLine2 { get; set; }
public string City { get; set; }
public string State { get; set; }
public string Zip { get; set; }
public string Country { get; set; }
public string PhoneNumber { get; set; }
}
Swagger will cleanly show both of these types if they are part of my DTO, however I can't convey that FirstName, LastName, or any of the Address properties are required or not. Is there a way to accomplish this without having to roll a separate spec document?
You can use an [ApiMember(IsRequired = false)] attribute on the properties in the DTO to add extra information for swagger ui.
There is list of the attributes that swagger ui will recognise on the servicestack wiki
I generate C# Class from http://json2csharp.com/ for any YouTube URL, in which some names are invalid like as follows:
public class Feed
{
public string __invalid_name__xmlns$media { get; set; }
public string __invalid_name__gd$etag { get; set; }
}
In the above code actual Youtube name is xmlns$media, gd$etag like that...
when I change those to:
public class Feed
{
public string xmlns$media { get; set; }
public string gd$etag { get; set; }
}
in C# it shows error because of special character $, If I don't use $ parsing doesn't happens and returns Null.
Help me fixing this!
Does this work for you?
[DataContract]
public class Feed
{
[DataMember(Name="xmlns$media")]
public string xmlns_media { get; set; }
[DataMember(Name="gd$etag")]
public string gd_etag { get; set; }
}
I am attempting to update an entry in Azure Table Storage. The function is:
public void SaveBug(DaBug bug)
{
bug.PartitionKey = "bugs";
bug.Timestamp = DateTime.UtcNow;
if (bug.RowKey == null || bug.RowKey == string.Empty)
{
bug.RowKey = Guid.NewGuid().ToString();
_context.AddObject(c_TableName, bug);
}
else
{
_context.AttachTo(c_TableName, bug);
_context.UpdateObject(bug);
}
_context.SaveChanges();
}
If it is a new entry (the "bug.RowKey == null" path), then it works fine. If it is an update to an existing entity, then the "AttachTo", and the "UpdateObject" calls work, but when it gets to "SaveChanges", it throws the "One of the request inputs not valid" exception.
The class that is being stored is:
[DataContract]
[DataServiceKey("RowKey")]
public class DaBug
{
[DataMember]
public bool IsOpen { get; set; }
[DataMember]
public string Title { get; set; }
[DataMember]
public string Description { get; set; }
[DataMember]
public string SubmittedBy { get; set; }
[DataMember]
public DateTime SubmittedDate { get; set; }
[DataMember]
public string RowKey { get; set; }
public DateTime Timestamp { get; set; }
public string PartitionKey { get; set; }
}
Does anyone know what the problem is?
Thanks for any help.
In case anyone is looking for the answer:
http://social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/0c9d476e-7970-422a-8b34-e987e41734df
Working through the table context, I had to change the call from:
_context.AttachTo(c_TableName, bug);
to:
_context.AttachTo(c_TableName, bug, "*");
You can also get this error if you mistakenly set the RowKey to a value you've already used (not that you'd get this problem with code in the question). I tried to push 50+ entities in one go and accidentally had the RowKey set to the same value for two of the entities.