I have a project that is working fine on my system. I can debug the project without problems. My development system is Win 7 (x64). When I deploy and/or publish this project to my test environment (Windows Server 2003 (x32)), I can no longer debug it. I keep getting an error that states "The following module was built either with optimizations enabled or without debug information." It is referring to one of the DLLs in my project that is from another project in the solution.
This application was originally created in VS 2005. I upgraded it to VS 2010 with no problems. I also felt that the original project needed to be re-factored, so I pulled all of the business and data layer logic and put it into a separate class library project within the solution. The web project also needed to be split up because the same code was running on two different server with different pages on both. However, there was shared presentation logic between the two web projects, so I created another class library project that was specifically for the presentation layer. After all of that, I now have 4 projects (2 class library projects and 2 web projects).
All of the web pages are working correctly, but it appears that I am having some issues with a web service (classic web service, not WCF) in one of the web projects. I am getting erroneous results and I am trying to step through it to find the problem. Please help! I have a pending deadline on this project.
You're building on a 64-bit system and deploying on a 32-bit system. This may be your problem.
Also, the account used while setting up remote debugger needs to have admin or power user privileges.
Third, can you debug any other assembly remotely? Try building a dummy console app and see if you can debug it remotely.
Also, once you attach a debugger, you can go to Debug > Windows > Modules > select your module and try to load the symbols manually. This may give you additional info as to why its not getting loaded.
Sounds like your pretty experienced with remote debugging but I posted three short blogs on my experiences last year that may help you. I was building on a 64 bit Win7 system and deploying to s 32 bit XP. First I had to upgrade my OS from Win 7 Home Ultimate to Pro. Secondly one of posts talks about the problems I had remote debugging the DEBUG build! I had to use a Release build and set some flags (detailed pic and info in the blog entry).
Remote Debugging a Release Build
General Remote Debugging advice (and screencast) from VS2008
Choosing the Right Version of Win 7 for remote debugging.
Have you tried this?
Go to Project -> Properties -> Build tab
Now make sure "Optimize Code" is unchecked.
Now go to Advanced in the same tab -> In the Debug Info drop down menu check full.
Related
I'm trying to use Visual Studio to develop and debug a web application that uses the SharePoint 2007 API. I have been doing this fine on a 32-bit server up until now. Today I've moved over to a 64-bit development server and when I try to run the project out of VS, I get:
Could not load file or assembly 'Microsoft.SharePoint.Search, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. An attempt was made to load a program with an incorrect format.
I have referenced Microsoft.SharePoint.dll and Microsoft.SharePoint.intl.dll from the GAC on this machine. That automatically copies in Microsoft.SharePoint.Search.dll from somewhere when I run it (even though copy local is false on the references). My project Platform Target is "Any CPU". I get the same error with x86. If I change to x64, I instead get Could not load file or assembly 'MyProjects.dll'...incorrect format.. I've also tried deleting Microsoft.SharePoint.Search.dll from the bin after it starts up but then I get a SharePoint error saying that the site at my URL can't be found, which I believe is also a bitness issue. I'm not quite sure what the issue is but want to be able to run this application out of Visual Studio. How can I get it working?
You need the x64 (or anyCPU) version of the Sharepoint dlls to make it work
Both Microsoft.SharePoint.dll and Microsoft.SharePoint.intl.dll in the server's GAC are built for Any CPU. When I build my web app in Visual Studio, it automatically copies Microsoft.SharePoint.Search.dll into my bin, presumably because it's referenced by Microsoft.SharePoint.dll. SharePoint.Search.dll is not in the GAC. It is copied from the 64-bit 12\ISAPI directory and is built with an "Amd64" target architecture (despite my server having an Intel Xeon CPU). So I believe the problem is VS runs the web app in a 32-bit process which causes the error when it tries to load the 64-bit SharePoint.Search.dll.
My first idea was to explicitly reference the 32-bit SharePoint.Search.dll in my project. That makes the error go away but it is replaced with an error saying the website at [my SharePoint site URL] cannot be found. I believe this is because now I'm trying to access the SharePoint site, which runs in a 64-bit app pool, from a 32-bit process. So what I really need is for Visual Studio to run my web app using a 64-bit hosting process. This looks like an option available for VS 2012, but not 2010. The alternatives I've found for VS 2010 are:
On the project properties Web tab, configure it to run using the Local IIS instance. This will add a virtual directory to the default site, which is running in 64-bit mode by default. This isn't a good solution for me because I want to allow multiple developers to work on the same project on the same server simultaneously. Using the same site would cause conflicts. If there were a way to configure the site name conditionally on the user, this would be ok. I opted to try #2 first.
Replace the VS Development Server with an x64 build of the CassiniDev project. This project has the capability of plugging in to VS in place of the default WebDev.WebServer.EXE. So you just need to download the source code, and build with an x64 target platform. Then you can replace the VS default development server exe, as is documented w/ the CassiniDev project, and it will run an x64 development web server which solves my problem!
All the sudden started getting the following error while trying to debug a worker role:
"Windows Azure Tools for Microsoft Visual Studio
There was an error attaching the debugger to the role instance 'deployment16(360)blah blah' with Process Id: '8780'. Unable to attach. The Microsoft Visual Studio Remote Debugging Monitor has been closed on the remote machine."
Restarting Visual Studio and the machine do not help.
As you start getting this problem all of sudden in your development machine something must have changed and it is mostly due to some of the OS auto-update and/or some application update you installed in your machine. There could be any random reason for this problem however if I would have hit the exact same problem here is what I would do to troubleshoot such issue:
To start, first thing is to just check it is not an application specific problem by creating a base app from web/worker template and see if that exhibit the problem.
If you have installed new release Windows Azure SDK 1.7 check with both SDK 1.6 and 1.7 to verify if both exhibit the problem.
Check if your could debug IIS based application as well outside Compute Emulator. This will isolate if the problem is specific to Windows Azure development Fabric or bind to your IIS itself.
If this is IIS specific issue, Check IIS configuration for all enabled functionalities, try resetting Application Pool configuration, running "ASPnet_regiis -i" etc to fix the issue.
If it is Windows Azure Computer Emulator specific, I know sometime OS updates may make application unstable so in that case, I will re-install .net 4.0 and VS2010 SP1 again respectively. (This does help so many time) then re-install Azure SDK 1.7 completely.
Such random problem mostly occur due to some change in your machine configuration, so restoring the VS2010 and the re-installing all other application does help to solve problems.
If you have an exception in the role's OnStart() or in Application_Start() that the debugger doesn't pick up, you may also receive this message. Application_Start() errors are especially pernicious because the debugger doesn't attach to the web process until after this method returns.
If you are wedded to cloud specific classes such as RoleEnvironment and cannot make the web role a startup project, you can use Ctrl-F5 to run the cloud project without debugging. With some luck you'll get a yellow screen of death to show you the true error.
Avkash covers the points.
I had the same issue recently. I set my web project as start-up rather than Azure and I discovered that that web project didn't actually run. Turned out somehow when of my projects was compiling for X64. I changed that and it worked.
I recently installed Visual Studio 2010 to help me with some exercises for class.
It all worked great in school but when I got home and tried to run and debug the second program I got this error:
Unable to start ...\Kapitel_1\Debug\Kapitel_1.exe
This application has failed to start because the application configuration is incorrect. Review the manifest file for possible errors. Reinstalling the application may fix this problem. For more details, please see the application event log.
How can this be solved?
This message generally means that the machine on which you built the application did not have the same redistributables than the system where you run the application.
Redistributables are sets of DLLs needed for your application to run properly.
In your case, I noticed that you are trying to run a debug build. That might just be the problem: you cannot run an application or use a DLL that has been built in debug configuration on a system with no debugger installed. Installing Visual Studio (ideally the same version your school has) should do the trick. You could also rebuild your application in Release configuration to avoid having to install a debugger on the running system.
Another case where this error message might be displayed is if you just installed a new Visual Studio update on the system that built the application and not on the system where you are trying to run it. In that case, you would need to update your system with the latest set of redistributables from Microsoft (at time of writing, here was a good place to look for that).
When trying to install a web setup project (MSI) created in Visual Studio 2010 on Windows Vista, Windows 7 or Windows 2008 Server the setup will fail, with some generic error.
According to http://devio.wordpress.com/2011/04/26/pitfalls-installing-web-setup-msi-on-iis-7/ this is because of a compatibility problem between the setup project en IIS7.
To resolve this I've to enable/install IIS6 metabase compatibility in my windows configuration. This workaround did fix the problem, but raises 2 questions:
Does this have any (negative) impact on functionality of IIS 7?
How can I notify a user running the installation of this problem so he or she can take proper action and install the metabase compatibility component? Is it possible to pop-up the windows component configuration dialog from this install, to make life easier for the user?
I don't think this will have any impact on the application itself, as long as it's implemented the way to talk to IIS7 via its native API. Otherwise, if it doesn't support IIS7 you'd have to enable IIS6 compatibility anyway.
The standard approach to search for anything on a target machine is searching registry and file system. I don't know how it is possible in VS setup project, but e.g. WiX has special elements for this (RegistrySearch, DirectorySearch, FileSearch). Basically, this post to WiX Tips and Tricks thread shows how to check for IIS6 compatibility in WiX and block the installation if it's not enables/installed. It's rather straight-forward even if you don't know WiX, but know the concepts of Windows Installer, and it can help you translate the code into the similar thing in VS setup project.
We seem to be having one negative impact on our servers.
Everytime we roll out a .NET 4.0 application with a msi made in Visual Studio, We get a recycle of ALL our application pools, even the ones not affected by the install.
Apparently the root cause of this is the IIS 6 compatibility. ( This was reported to us by a developer of microsoft in response to our support question about this.
At the moment we have no solution. It's impossible to convert all our installers to Wix.
I've spent waaaay too much time trying to figure this out. I'm running Windows 7 and Visual Studio 2010 in a VMware Fusion virtual.
When I debug my website project, Cassini (aka ASP.NET Web Development Server) starts and the site shows in my default browser (IE). I stop the debugger, make some tweaks to my C# code, and start the debugger again. The website starts up in IE and the site displays, but its using the code base from when I initially debugged NOT including any tweaks in code between the initial debug/build and subsequent debugs/builds.
The only way I can get code changes to build and run in the browser properly is if I manually stop the ASP.Net Web Development Server from the tray and then run debug.
Has anyone encountered this? Not sure if its caused by VS2010 or the environment being a virtual on a Mac.
Manually stopping Cassini after every debug is really starting to suck.
Thanks.
Check if Visual Studio is set to recompile the projects when there are changes.
Check that Tools > Options > Projects and solutions > Build and run > On run, when projects are out of date is set to Always build.
Perhaps you will have a more pleasant experience with IIS 7.5 Express as a replacement for Cassini.
From that page:
IIS Express is a lightweight,
self-contained version of IIS
optimized for developers. IIS Express
makes it easy to use the most current
version of IIS to develop and test
websites. It has all the core
capabilities of IIS 7 as well as
additional features designed to ease
-- website development including:
-- It doesn't run as a service or
require administrator user rights to
perform most tasks.
-- IIS Express works well with ASP.NET and PHP applications.
-- Multiple users of IIS Express can work independently on the same
computer.
Here's an article to help you get started.
Figured this out. I had mapped my Visual Studio 2010 folders to a VMware Fusion share in order to make my .NET projects accessible from Mac world (for copying graphics files into the projects, etc.). Evidently there was some type of permission issue or something that did not result in any sort of alert that was causing the problem.
I remapped all VS folders (Project, Website, etc.) into the standard Documents folder of my user instance and everything began working as expected.
Thanks for the help.