I'm currently trying to learn F# and am having some problems with the Visual Studio 2015 debugger. Taking the following code as an example (I'm playing around with ASP.NET Web API):
[<Route("api/HomeApi/VideoCapture")>]
[<System.Web.Http.HttpGet>]
member this.VideoCapture() : HttpResponseMessage =
let response = this.Request.CreateResponse()
this.SetupCameraConsumers()
this.SetupCapture()
response.Content <- new PushStreamContent(this.Test())
response
I have put a breakpoint at the first line in this method, stepping over the 'let' works fine, but when I try to step over the next line, VS debugger essentially continues to the end of the method without throwing any errors. Within the this.SetupCameraConsumers() call, I am simply adding some objects to a list and returns a 'unit'.
Has anyone come across anything like this before? If I can provide any more information please let me know - I've used the VS debugger for C# code and have never encountered anything like this.
Am I calling a method correctly? Is this allowed in F#?
Thanks!
Just for anyone else who may run into this issue, disabling the debugging option 'Just my code' allows me to step over the code. I'm not entirely sure why that should make a difference though. Thanks again for the helpful comments provided.
Related
Original class function creates an SQL query and executes it.
Since there is an syntax error in the query it throws an error. What's the correct way to achieve fixation? Class extension does not work, because CoC executes the complete original function.
originalFunction(..)
{
createSomeSQLQueryWithSyntayErrorInIt();
executeQuery();
}
The class in question is ReqDemPlanMissingForecastFiller. In method insertMissingDatesForecastEntries a direct SQL statement string is generated. The date variable nonFrozenForecastStartDate is added to the string, but is not escaped correctly as it seems.
If the SQL statement is executed, a syntax error occurs. If the statement is fixed, it can be executed e.g. in SQL Server Management Studio (SSMS).
In this specific case, based on your comments, you may be able to sidestep.
Create a new class ReqDemPlanMissingForecastFiller_Fix extending ReqDemPlanMissingForecastFiller then copy/paste the erroneous function and correct the mistake.
Create an extension class and change the newParameters static funcion.
[ExtensionOf(classStr(ReqDemPlanMissingForecastFiller))]
class ReqDemPlanMissingForecastFiller_Extention
{
public static ReqDemPlanMissingForecastFiller newParameters(
ReqDemPlanCreateForecastDataContract _dataContract,
ReqDemPlanAllocationKeyFilterTmp _allocationKeyFilter,
ReqDemPlanTaskLoggerInterface _logger = null)
{
ReqDemPlanMissingForecastFiller filler = next newParameters(_dataContract, _allocationKeyFilter, _logger);
filler = new ReqDemPlanMissingForecastFiller_Fix(); //Throw away previous value
filler.parmDataContract(_dataContract);
filler.parmAttributeManager(_dataContract.attributeManager());
filler.parmAllocationKeyFilter(_allocationKeyFilter);
filler.parmLogger(_logger);
filler.init();
return filler;
}
}
Code above was based on AX 2012 code. Stupid solution to a stupid problem.
It goes almost without saying that you should report the problem to Microsoft.
#Jan B. Kjeldsen's answer describes how the specific case can be solved without involving Microsoft.
Since overlayering is no longer possible, the solution involves copying a fair bit of standard code. This brings its own risks, because future changes by Microsoft for that code are not reflected in the copied code.
Though it cannot always be avoided, other options should be evaluated first:
As #Jan B. Kjeldsen mentioned, errors in the standard code should be reported to Microsoft (see Get support for Finance and Operations apps or Lifecycle Services (LCS)). This enables them to fix the error.
Pro: No further work needed.
Con: Microsoft may decline the fix or take a long time to implement it.
If unlike in this specific case the issue is not a downright error, but a lack of extension options, an extensibility request can be created with Microsoft. They will then add an extension option.
Pro: No further work needed.
Con: Microsoft may decline the extensibility request or take a long time to implement it.
For both errors as well as missing extension options, Microsoft also offers the Community Driven Engineering program (CDE). This enables you to develop changes in the standard code directly via a special Microsoft hosted repository where the standard code is not locked for changes.
Pro: Most flexible and fastest of all options involving Microsoft.
Con: You have to do the work yourself. Microsoft may decline the change. It can still take some time before the change is available in a GA version.
You can also consider a hybrid approach: For a quick solution, copy standard code and customize it as required. But also report an error, create an extensibility request or fix it yourself in the CDE program. When the change is available in standard code, you can then remove the copied code again.
I am taking over an ASP.NET MVC application from someone who left. The application was developed using .NET Framework4.
Everything was working fine, until an automatic security update was pushed to the system.
Basically, the following statement now throws a NULL exception after the push of KB4024848:
object obj = typeof(HttpRuntime).GetProperty("CacheInternal",BindingFlags.NonPublic|BindingFlags.Static).GetValue(null,null);
Looks like the key string "cacheInternal" is not recognized anymore.
Rollback of KB4024848 would make the statement work again.
Any idea about this issue, as well as what could be an alternative solution to get the same object value? (This statement is part of a section of code trying to get a list of active sessions, using InProcSessionState.)
Your solution to this question will be greatly appreciated, since we have been spending quite sometime to work on it.
When I build my website project using visual studio 2016 (or any visual studio for that matter), the compiler gives me an error:
However if I go to the code file ResetPassword.aspx the edtEmployeeSurname control is present and it has a runat="server" attribute.
There is also no errors given to me if I open the ResetPassword.aspx.vb code file. (So no red lines under any variable names / Control ID's).
What is really interesting is that the website (Even ResetPassword.aspx) loads correctly from the browser without any issues and I can submit the form.
If I comment out all the code in ResetPassword.aspx.vb then it just finds another control that "Doesn't Exist" and so it carries on with a lot of pages.
All I want to know is:
What causes these issues
How to fix these issues OR how to determine what the issue is.
If this is a common mistake that some developers make then please help me to formulate a search string to use in google, because most of my search results were obscure or off topic.
I've run into this sort of thing before and I believe the errors you are seeing are red herrings. They lead me to believe that one of your lower projects where your user controls are defined, or possibly even lower than that, has a possibly unrelated error in it which is causing it to not be built by visual studio, which in turn makes visual studio think your user controls aren't defined.
What I normally do is build the solution and watch the output window. It will build all of your projects individually, the first error you see pop up in the output window is the source of your problem. Everything else you are seeing is a symptom of that original issue. If you fix the first error that shows up in your output then it will either build correctly or you will have to repeat the process with the next error that pops up.
Visual Studio used to order the errors in the error list in the order that they came up during the build but that has changed, I, personally, really preferred the old sorting(I think there is a setting that you can use to get back to the old sorting but I can't think of it off the top of my head).
From screenshots, it shows you have 50 errors in your project. There is no way an application will run successfully if you have not set to do so.
You could make application run, even if errors.
Check SO post :
Debugging runs even with compiler's errors in Visual Studio
Note:
If you have already cleaned and rebuilt solution,
Try running application in other browser or another computer, may be you have data shown from previous successful result.
Based on the wording of the error, I believe it's possible you are referring to some of these controls outside the code behind of ResetPassword.aspx. The latter part of the message says It may be inaccessible due to its protection level. By default, the backing variable for a control you place on a form is Protected and therefore cannot be seen outside the scope of that control or its inheritance chain.
I'm using reactive extensions (well, trying, learning) in a windows store app. I have a series of async operations that will eventually navigate to an authorization web page for RTM. Given the reading I've done, I would expect to write something like the following:
var result = rtm
.GetFrob()
.Select(s => rtm.GetAuthenticationUrl(s))
.ObserveOnDispatcher()
.Do(uri => AuthWebView.Navigate(new Uri(uri)))
.First();
However, I can't seem to find a method ObserveOnDispatcher, and further there is no Scheduler.Dispatcher property either, leading me to think on a Windows Store application there is something deeper gong on with the main UI thread and how you reference it.
GetFrob, btw, creates an IObservable sequence using Observable.FromAsync (if that helps with this).
BTW, if I remove that line, I fail in the call to the Navigate as posting it from the wrong thread. So, what is the proper thing to do here to make sure I'm back on the correct thread?
BTW, Excuse the ".Do" operation here, I know it isn't "nice", however, I'm still experimenting in throw-away code.
Many thanks in advance!
Argh. Apparently I just am not good enough at search. :(
Turns out that adding the nuget package Rx-Xaml includes the proper assemblies for the scheduler, etc. Details can be found on the main Rx blog. Of course, my app is back to hanging now, but that may be due to something else dumb on my part.
We're running on .NET 3.5 SP1.
Recently, in IE, some of our users started getting "Out of Memory" errors once in a while. This doesn't happen all the time. I managed to replicate it a couple times and I found that this code, from the AjaxControlToolkit.Common.Common.js file, was causing an infinite loop:
AjaxControlToolkit.TextBoxWrapper.registerClass('AjaxControlToolkit.TextBoxWrapper',
Sys.UI.Behavior);AjaxControlToolkit.TextBoxWrapper.validatorGetValue =
function(id) {
var control = $get(id);if (control && control.AjaxControlToolkitTextBoxWrapper)
{
return control.AjaxControlToolkitTextBoxWrapper.get_Value();}
return AjaxControlToolkit.TextBoxWrapper._originalValidatorGetValue(id);}
The last line (which calls _originalValidatorGetValue) basically calls back this exact function over and over because control.AjaxControlToolkitTextBoxWrapper is undefined.
The function defined right above it is AjaxControlToolkit.TextBoxWrapper.get_Wrapper(control) and could be use to create the wrapper if it doesn't exist, but I don't get the feeling I want to be changing the framework if I'm the only one who's seen this bug in the wild.
The bug does not always occur. It seems to occur when the first URL that is loaded contains an AJAX history point. If you open up a page and play with it, causing history points to be added, it works fine. But if you copy-paste the URL into another browser windows, you will get this problem.
Therefore, my guess is I am doing something wrong with the history control that doesn't setup the wrappers properly. Even so, there appears to be an infinite loop in there.
Any ideas/clues?
I filled out a bug report on Microsoft Connect. While filling it out and testing various scenarios, I noticed it was working fine locally but not remotely. Comparing my production/development environment, I noticed CombineScripts was false locally. Deploying that to my production server seems to have resolved the issue.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=373171
If you remove LoadScriptsBeforeUI='false' from ScriptManager, this problem is solved.
You might want to post a bug report on Microsoft Connect.