So I'm a lucky boy, I've been tasked with upgrading the development environment but not the code of a monster classic ASP product. It has been developed over several years and contains huge amounts of superfluous code in.
In order to modernise the development environment I'm targeting the IDE and moving away from FrontPage (yes, I know!); I've created an empty .Net project in VS2015 Community edition, manually added the legacy classic ASP code.
The advantage is by using VSnn it can be linked into TFS seamlessly and allow proper SDLC process to be enforced.
The problem is, I cannot attach a process in order to debug because the legacy code does not compile when I Build -> Build Solution. As I understand it the solution must build in order for the break points to be enabled?
There are 4 error types repeated hundreds of times during build;
Statement cannot appear outside a method body
Identifier expected
Declaration expected
End If must be preceded by a matching If
My questions are, how can I debug this beast if it will not compile?
Is it possible to ignore these warnings for a successful compile?
Is it possible to add break points and hit them in VS2015 for script only debugging?
And yes, I would burn this beast to the ground and use .Net but its not an option.
Something doesn't add up here. Classic ASP files aren't compiled, they are evaluated at runtime. I created a test project with both a WebForms page and Classic ASP page. Both worked by default. I attempted to reproduce your scenario by removing an opening if block but didn't receive any compile errors or warnings.
I am using VS2015 but would suspect to see the same since at least VS2012 if not early versions.
Related
I try do debug a blazor webassembly app, that references a shared project named Test.Shared. I've been trying to set breakpoints in that projects code but nothing helped - breakpoints just aren't hit.
When I'm trying to set a breakpoint outside in the calling code and then step into "Test.Shared" source - it just seems to go step by step through the underlying code (I have to hit "step forward" multiple times before it proceeds the debugging to the next line, and the number of hits changes when I reduce/increase the number of lines in the underlying method code) but its not displayed in the debugger window.
So, after some investigation, I figured out that I can make the debugger work when I throw away all the code from the Test.Shared and leave only one simple test static method. Based on this fact I guess there is some specific type of C# code that causes the whole containing library to be invalid for debugging.
Any suggestions what this code type might be?
The environment I use:
Visual Studio Enterprise 2019 16.6.2
NET Standard 2.1 as a target platform for both Blazor app and shared library
NET Core 3.1 as a target platform for the hosting web app that serves webassembly app packages
Microsoft.Components.WebAssembly 3.2.0
The issue is with having attributes that have enum values inside of them.
Many people are having this problem and it's better explained in Blazor Wasm: debugging broken when referencing #attribute with enum contructor argument #25380 by zbecknell:
Here's a simple repro project: https://github.com/zbecknell/Undebuggable.
See Counter.razor:4 for the line that breaks debugging for the project:
#* The following line breaks debugging for the project, no matter how long you wait *#
#attribute [BadAttribute(BadEnum.Default)]
I'm trying to track down an issue with MVC so I thought I would step into the ASP .NET Core source code. I've unchecked "Enable Just My Code" and I've checked "Enable .NET Framework source stepping" (although I guess that's not necessary). I've also checked "Enable source server support" and enabled the Microsoft symbol server.
I step into this line
app.UseMvc();
and eventually I get to this code in MvcApplicationBuilderExtensions.cs.
VerifyMvcIsRegistered(app);
var options = app.ApplicationServices.GetRequiredService<IOptions<MvcOptions>>();
if (options.Value.EnableEndpointRouting)
{
Stepping through this code the program counter starts to jump around and I receive an error that several of the local variables cannot obtain the value because it is not available or it's been optimized away. I assume this is because the source file and the symbol files don't match.
I'm running this on Visual Studio 2019. It's .net Core 2.2.203. I've deleted the symbol cache and the SourceServer cache. I'm trying to figure out what I've done wrong in my code and exactly why.
Actually, I've tried to debug .NET source code several times over the past several years and I always have the same issue. None of the online help seems to have an answer. Am I doing something wrong or is this just unreliable?
The message is accurate and explains exactly what happens. It has nothing to do with mismatched symbols.
The (non) problem as the message explains is that the IL has been optimized during compilation, those variables no longer exist. A Release build performs a lot of optimizations that usually end up eliminating parts of the code that aren't needed.
Functions can and quite often are inlined. A variable may be replaced by a register for example. A loop may be eliminated entirely. When that code runs the variables or functions are no longer there so they can't be displayed.
Debug symbols can still be generated in a Release build. They'll reflect the IL generated for a release build though. One would need assemblies compiled in a Debug configuration to get IL that matched the source without any optimizations.
That's true for the .NET Core runtime, our own code when run a Release build and all NuGet packages.
If you want to debug .NET Core source code you can download it from github (https://github.com/dotnet/corefx). It's very easy to debug, like your own project.
There is very good video, where explains how .NET Core MVC request life cycle works (https://app.pluralsight.com/library/courses/aspnet-core-mvc-request-life-cycle/table-of-contents), maybe there you can find information which you need.
P.S. you can get 3 months free in pluralsight with microsoft account.
I am working on a nodejs project in which all code is written in typescript. It follows a microservice pattern (and each microservice is an independent project) hence lot of projects needs to be opened and debugged at the same time.
I tried webstorm and visual studio (with NTVS) but not satisified with both of them. Webstorm ignores many build errors (very important as those will fail during CI) and not as good as visual studio in intellisense and ease of use. On the other hand, Visualstudio is not as fast as I want. Also I am tied to windows and the filename length problem in node_modules is very frequent and annoying.
Others (atom, VSCode) doesn't have typescript debug support (or am I missing something?).
Can you please share your experience? Also I was wondering which editor google developers might be using to develop angular 2 :)
I have been working on a TypeScript project for 1.5 years now and am quite happy with using Visual Studio because we used .NET for back-end stuffs. For myself I consider the speed as "Ok", it is not that good - but the other stuffs e.g. intellisense is what we really like. I also personally think that as a "son" of Microsoft, TypeScript will get the best support from its "cousin" - Visual Studio.
However if you are a Eclipse person, you may be interested in this TypEcs (http://typecsdev.com/). There was also a post by Steve Fenton talking about TypeScript IDEs you may be interested (https://www.stevefenton.co.uk/Content/Blog/Date/201409/Blog/Which-TypeScript-IDE/), he listed a few of the popular ones with a few sentences of comments, including Atom and the atom-typescript extension.
A bit late to the conversation.
I recently tried VisualStudio 2015, VisualStudio Code 0.9, Atom (with Atom-Typescript package). And quite comfortable with Atom.
Atom-TypeScript uses the latest version of TypeScript so you can use all new features like async/await, string interpolation etc. The package created by community so we don't need to wait for major IDE release to use new TypeScript features.
For debugging couldn't find one. But love to use node-inspector for its light weight. The problem is you need to debug it in javascript version not in typescript version. Not so sure but maybe if you can provide map file you can debug the typescript version? like we have on Google Chrome Inspector.
VSCode can debug in Node. No browser debugging yet.
Not a recommendation, but I suggest you do not buy JetBrains' products (IntelliJ/WebStorm/ReSharper) for TypeScript editing unless you have evaluated them properly.
They reused a lot of their own logic for other languages instead of taking full benefit of the TypeScript language service, which means they behave more like a fancy JavaScript editor that can make some clever guesses as opposed to a robust IDE for a statically typed langauge. (Their type inference is different from the compiler and may fool you into believing an untyped expression (implicit any) is well-typed. Also, all the refactoring are the same as the JS ones, so they do not use or preserve any type information. No type-information-based refactoring (like safe renaming and moving) are available either.)
As for debugging, you may have more milage debugging the generated JS. Not only is it well supported, it also reveals problems that occur in compiler-inserted code. The latter would be otherwise difficult to understand if you're only looking at the TypeScript source. Also, in the generated code, you can actually set break points in single line lambda function bodies.
I too use Visual Studio. I haven't had any problem with its speed; I find everything is as immediate as I expect it too.
However, I haven't been using "TypeScript" projects. I have been using generic "Web" projects with TypeScript files. Plus, I don't use Visual Studio's own building and compilation facilities; I use my own Gulp tasks for my project (including rebuilding, watching for saves, minification, testing, etc), and Task Runner Explorer to manage/run them from inside Visual Studio. I think it's the best of both worlds: the snappiness and features of Visual Studio, and the flexibility of running my own custom tasks independent of platform.
I have to admit I don't do any deep debugging (e.g. breakpoints, stepping) from the IDE. Does VS do that with TypeScript? If I catch an error during execution (in the browser), I always have my source maps indicating where the error is, so I go back to the code, attempt to fix it, save, and reload in the browser.
I am using VSCode to actively debug an angular/node/typescript application. It does work, but you will need to do some setup/configuration. You must tell VSCode how to debug your applications. For instance I have multiple options in my launch.json configuration to debug my gulp scripts, my node server.js file, and the angular/typescript application via chrome using the "Debugger for Chrome" extension installed in VSCode. It is all possible with some configuration. Finally, depending on your exact situation you may need to have and correctly configure the map files for your project from javascript to typescript.
I also had the problem of file paths too long in the node_modules folder in visual studio when opening a project with npm. This is due to Visual Studio trying to download all your packages - incorrectly so I might add. The only way to avoid this for my project was to mark the node_modules folder as a hidden folder in windows (top level only).
I'm running VS2010 Version 10.0.30319.1 RMTRel
I've noticed problems compiling VB.NET application. When I "rebuild" the solution it reports the build was successful. When I then click the run icon to begin debugging, then the compiler will report build errors(often related to referenced projects). I've confirmed all the projects are targeting the same framework and after an undeterministic number of times repeating the same steps, it will eventually compile. This seems consistent enough to me with other code bases to believe that it's a problem with VS. Anyone have any thoughts that might help improve my experience?
You should also check your configuration manager - probably some of projects are disabled for building in current build plan.
is this a rather large solution? If so, the order of build may be out of whack and the way to solve that is to set the build order of the projects to make sure all of the dependent projects are built first.
One common reason is circular references. You cannot do this in a pair of projects, but it can be done if you cobble together a long string of projects. The way to catch this is a dependency mapping tool with a visual representation of dependencies. You will see the items that refer back up to the top.
So, I just downloaded VS 2010 Beta 2, and when I try to build one of my class libraries with several resource files, I get the error:
"The specified task executable "ResGen.exe" could not be run. The filename or extension is too long"
before that, I get the warning:
Warning 4434 The command-line for the "ResGen" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of the command-line by breaking down the call to "ResGen" into multiple calls with fewer parameters per call.
Both of which, I am SURE tell me exactly what the problem is, but its not clicking with me. Since this assembly works in VSTS 2008, I am at a bit of a loss.
If necessary, I'll enter a bug with MS, but I wanted to see what the collective wisdom of stackoverflow can do for me first.
I'm having the exact same problem. I've submitted the issue on the Microsoft Connect site:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=499196
I changed my projects to target .NET 4, and this problem went away.
Not an ideal solution though, as we're not ready to build to .NET 4 yet, but at least the product is usable.
UPDATE: Microsoft have posted an update to the connect issue:
Workarounds
1) switch to target 4.0. Obviously that isn't a workaround for a serious project, but it fixes it for experimentation.
2) I didn't try this. Go into \microsoft.common.targets and find the GenerateResource task. Make a backup of the file first. Change the Condition attribute to:
Condition="'%(EmbeddedResource.Type)' == 'Resx' and '%(EmbeddedResource.GenerateResource)' != 'false' and '%(EmbeddedResource.Identity)' != ''"
The extra clause should make resgen run separately on each input file, which will be slower, but should avoid the problem.
Dan
I changed the Condition as noted, and everything is working fine so far, whilst still targeting .NET 3.5. It is noticibly slower :)