TextBoxFor with red underline in razor - razor

I Have a aps MVC razor project, where the razor pages, show a error in the razor helpers than use a lambda expression,
for example:
#model Person
#Html.TextBoxFor(c=>c.Name)
is marked with red underline, and c.Name does no have intelisense.
But if i use
#Html.TextBox("hello")
is not marked with the red underline.
This does let me compile, and execute, but it's annoying, because of the lack of intelisense in the lambda expressions.
the error that gives is:
the type arguments for method cannot be inferred from the usage
Some things I have tried
to change a little the structure of the call:
#(Html.TextBoxFor(c=>c.Name))
Then only the lambda expression is in red and the error says:
cannot convert lambda expression to type because it is not a delegate type
I have the
<compilation debug="true" targetFramework="4.0">
with the targetFramework of my project, and all the other helpers that not uses lambda don't give this error.
What can it be?

I had this problem just now, and I know that it might not be help at all for you since this reply comes 2 years later, but searching in google this was the first result and I worked out a solution.
Turns out that there was a problem (I don't know why) with the "System.Core" reference. I tried to remove and add that reference again but I got an error when adding it. So I searched a bit more and discover that Microsoft made that reference even if it is not visible on your project so to add it again you need to edit the "*.csproj" yourself. I opened it with VS Code (you can even use Notepad) and then added:
<Reference Include="System.Core" />
I did it alphabetically like every other reference but I don't think that's important, in my case that was after "System.ComponentModel.Composition". Hope that this can help you if it happens to you again and maybe help anyone else that finds this question.

Related

Handling Logstash Plugin Filter errors gracefully

So, I'm building a plugin for logstash and I can't seem to find any documentation on how I should handle exceptions thrown and or rescued. So far, and similar to grok, we're adding a event["tag"] = ["_filter_error"], but in regards to metadata like a stacktrace, error type, etc... where should those live, or should they be omitted?
This is sort of a case-by-case question, so admittedly hard to answer. But I'll share how we ended up doing it so it might help someone.
Rescue all the exceptions (LogStash will hang otherwise)
Add a tag to the event event["tags"] = ["_filter_error"] so these can be query-able down the road
Ignore the stacktrace and error message (our decision - basically use the tag instead)
Use a single field as metadata about the tag we added to the event. For instance, if our filter blew up altogether, honey-badger it and move on. If our filter failed 1/2 through filtering, add as much data to the event as you can, add the tag in step 2, then create a metadata field (i.e. event["unknown_tags"] = [1,6,7] where our filter blew up at tags 1,6,7 but passed for everything else)

found invokx in this source code

I'm very new to masm.
Was trying to read this source code I found online and I came about invokx,
which is not invoke. Can't find anything on it around, strange, can anybody explain? can it be just a typo?
code snippet here
invoke Install
invoke EnumProcs
invokx _ExitProcess, 0
and another snippet too in some other part of the code
#nomore:
;; Dedstroy handle
invokx _CloseHandle[ebx], hSnapshot
any help will be much appreciated , thanks
Judging by your code snippets, it's probably the macro defined here.
As the code is from the Tinba banking trojan, there's this article that talks about it:
‘GetBaseDelta’ and ‘invokx’ are macros predefined in the code. As its
name suggests, the first one calculates the delta offset and puts the
result in ‘ebx’ register [...] The second macro calls an API function
based on the contents of ‘ebx’ register (i.e. by taking into account
the same delta offset).
It seems that invokx can also work like the standard invoke.

Custom control casting exception during DesignTime but not RunTime

Been dealing with a casting exception during design time only that getting me nuts.
I'm trying to create a custom control for winRT (a week view control just like windows phone 8.1). The control works fine during run time but in design time it gives me COMException. During my investigation of the cause of this COMException, I found out that there is a casting exception inside one of the component of my control. This component is a custom listview that implement ContainerContentChanging event. Inside this event there is a casting which raises this exception.
Here is a the custom list view class:-
The code is removed coz the source code is shared below.
The TemplatedListViewEntry cctor look like this one:-
The code is removed coz the source code is shared below.
And the AppointmentModel:-
The code is removed coz the source code is shared below.
OBS!!! while debugging using 2 instance of VS or VS+Blend and put a breakpoint before this line I can see that args.Item is of type ContentControl while during run time it is AppointmentModel.
Could it be a problem with the ItemsSource which is null at design time?
If yes how should I preceed and assign this_ If No, anyone here that can help me figure out what is the problem?
OBS!!! I anyone needs more info please ask and I would gladly share the entire code with you.
Edit 1
Even if i initiate my viewmodel in the cctor of the custom Control, it raises casting exception in Designtime and not in Run tim
Edit 2
After i wrote Edit 1 above i noticed that now i have to Cast exception in two different Styles (CustomWeekView style and TemplatedListView Style) this is if you open Generic.xaml inside Blend. It is really getting annoying and i'm out of thoughts now. That is why i decided to share the source code of this Project, hopfully someone will be able to help looking at it. Below you will see the source code.
CustomWeekView

Is better Razor diagnostics change now included in ServiceStack v3.9.45?

As I'm still getting HttpCompilationException (External Exception) when I work through Mono on Mac with no hint as to what the real error is within Razor. To test it I'm binding to an invalid property name in a model. If I use the correct property name it works.
The project has GitHub issue here: https://github.com/ServiceStack/ServiceStack/pull/561
Is this change now included in v3.9.45? Do I have to do anything extra to enable it? I've got DebugMode on but that just adds stack trace data.
The Razor support was rewritten and my original change to improve the debugging experience wasn't carried forward (originally). It's now been added, see this comment:
https://github.com/ServiceStack/ServiceStack/pull/561#issuecomment-18204358
And this is the pull request that added it.
https://github.com/ServiceStack/ServiceStack/pull/684
It was included as of 3.9.47

XAML Deserialization problem

I have a block of XAML of which i'm trying to deserialize. For arguments sake lets say it looks like below.
<NS:SomeObject>
<NS:SomeObject.SomeProperty>
<NS:SomeDifferentObject SomeOtherProp="a value"/>
</NS:SomeObject.SomeProperty>
</NS:SomeObject>
Of which i deserialise using the following code.
XamlReader.Load(File.OpenRead(#"c:\SomeFile.xaml"))
I have 2 solutions, one i use Unit Testing, and another i have for my web application. When i'm using the unit testing solution, it deserializes fine and works as expected. However, when i try to deserialize using my other project i keep getting an exception like the following.
'NameSpace.SomeObject' value cannot be assigned to property 'SomeProperty' of object 'NameSpace.SomeObject'. Object of Type 'NameSpace.SomeObject' cannot be converted to type 'NameSpace.SomeObject'.
It's as if it is getting confused or instantiating 2 different types of objects? Note, i do not have similarly named classes or any sort of namespace conflict. The same codes executes fine in one solution and not the other. The same project files are referenced in both.
Please help!
Resetting IIS seemed to have fixed the problem. XAML must have been using a shadow copy of the DLL's sigh