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 :)
Related
I'm updating projects in a .NET Framework solution containing a DLL and an EXE to target .NET 5.0. Every call from the from the EXE which touches the DLL is marked with the warning:
Warning CA1416 'MyDllClass.MyProperty<int>(ref int, int, string)' is supported on 'Windows' 7.0 and later
The suggested actions from Microsoft basically amount to either adding cruft to every call or just giving up and suppressing the warnings. Logically, I expected to be able to mark my EXE to declare that it was targeting Windows 7.0 or higher, so that it would give an exception if anyone tried to run it elsewhere, but the compiler could assume this was the baseline for all API calls. Two things I tried, neither of which helped:
Attempt 1
<SupportedOSPlatformVersion>7.0</SupportedOSPlatformVersion>
Attempt 2
<TargetFramework>net5.0-windows7.0</TargetFramework>
What is the elegant way to address this situation? The fact that I'm in control of both projects seems like the best-case scenario.
From EXE Project:
<OutputType>WinExe</OutputType>
<TargetFramework>net5.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
From DLL Project:
<TargetFramework>net5.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
Thanks to a comment by Hans Passant, I tried removing this from my EXE project:
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
I also had to remove the AssemblyInfo.cs due to auto-generated fields conflicting with fields defined in there. After that, all good, no warnings. I presume the compiler is generating whatever fields it needs to keep itself happy.
I also guess that this would not be an issue on a green-field project and that I only ended up with that element somewhere in the process of migrating the application.
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.
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.
I recently added a new project to my Visual Studio 2008 solution. Now, as I make edits in the new project, I receive a ton (~50) of type checking errors - indicating that an assembly reference may be missing. However, when I actually build the solution, the errors go away. As best I can tell, my dependencies are set and the build order is correct. What could be wrong?
It doesn't prevent me from building and deploying, but it's a major nuisance. It makes it hard to tell when I actually have introduced new errors (until I do compile). Thus, it erodes the usefulness of having the error window do static analysis.
Example, one of the 50 errors is this:
"The type of namespace name 'PersonManager' does not exist in the namespace 'Gideon' (are you missing an assembly reference?"
In reference to this line of code:
Gideon.PersonManager pm = new Gideon.PersonManager()
PersonManager is underlined in both places, and when I right click the type and selected 'find all references' I get an alert box that says "Cannot navigate to PersonManager"
However, the references are definitely there, because when I build, it works.
One other detail is that there is a mixture of C# and VB.net code, though I don't think that should make a difference.
Well, yes, the IntelliSense parser is not an exact replica of the C# compiler. It has a very different job to do, it needs to do something meaningful while the code is utterly broken since you are editing it. Tough assignment, they did a tremendous job with it. But as a side-effect, it can fail to parse things that are actually legal. It's quite rare but not unheard of, seen it myself a few times.
This won't go anywhere concrete until you at least give us some idea of what kind of errors you are seeing, along with a snippet of the code that generates them. You didn't do so, I can only recommend that you select another window so you don't have to look at them.
I had the same problem. I had a project in my solution that was causing the problem - I removed the project from the solution, then added a reference to that project in the main solution and the errors went away. Strange that it only happened on 1 machine. Opening the solution on another machine was fine...
I met a lot of problems when I'm trying to compile with VS2008 on Vista. Because I'm new to VS2008 and new to programming in Windows, I'm totally lost when errors happen.
My problem is as following:
The vs2008 has anyway been installed and I tried to build a open source app
and the compilation stopped due to errors. In the output window I see:
1>fatal error C1900: Il mismatch between 'P1' version '20080116' and 'P2' version '20070207'
Totally mess for me!!!
Found a thread on this error: http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/9abfefe0-56bd-4a82-ae14-b08f262972bd
Sounds like you need to install VS2008 Service Pack 1. You should probably also make sure you're up to date with the latest .NET releases.
P1 and P2 refer to the "passes" made by the compiler over your code. Microsoft's C++ compiler is a two-pass compiler. The first pass generates data (in some kind of intermediate form) that's given to the second pass for actual conversion to machine code.
These are implemented in c1.dll and c2.dll.
The error is essentially complaining that you've got mismatched versions. Try a repair install, or install VS2008 Service Pack 1.