There are quite a few solutions out there for this one but they all pertain to the actual IIS box. I am Unable to publish at all the publish process fails with the following error:
Could not load file or assembly 'file:///C:\Users\user\Documents\VSSolutions\myWebApp\myWebApp\bin\AjaxControlToolkit.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
I CAN and successfully do build/run and test the app on my local machine.
This is an isolated problem to my specific machine as in my other developers are able to do the publish after I check in all of my changes!
Here is everything that I have tried.
enabled 32 bit on IIS
gave full rights to Temporary ASP.NEt folder at several different locations based on offered solutions
dll file is NOT blocked!
I am using VS 2022 AND VS 2019 and the same issue persists on both!
Please help :)
I saw another Stack Overflow post to make sure anti-virus is not blocking a temporary ASP.NET folder. In my case turns out that was the case indeed. Anti-virus was blocking my publish from completing...
Related
Is anyone able to offer me some advice...
I've got a repository with 2 solutions in it. Each solution is made up of multiple projects. One solution is .NET 4.8 the other is .NET CORE 3.1.
These solutions run locally in docker containers.
In VS2019 I can attach to process and debug both of these containers/solutions. When I look at the modules window I can see "User Code - Yes" and "Symbol Loaded - Server Side Symbol" (or something similar to that).
In VS2022 I can attach and debug the .NET 4.8 solution but when I attach to the .NET CORE 3.1 solution I get an warning message saying:
"The breakpoint will not currently be hit. No symbols have been loaded for this document".
When I look at the modules window in VS2022, I can see my DLLs are all marked as "User Code - N/A" and "Cannot find or open the PDB file".
Additionally, if I right click the DLLs and select Symbol Load Information, I can see something like this:
C:\solution\src\Project\MyStartUpProject\rendering\bin\container\Debug\netcoreapp3.1\MyComponentProject.pdb: Cannot find or open the PDB file.
C:\solution\src\Project\MyStartUpProject\rendering\bin\container\Debug\netcoreapp3.1\MyComponentProject.pdb: Cannot find or open the PDB file.
C:\solution\src\Feature\MyComponentProject\rendering\obj\container\Debug\netcoreapp3.1\MyComponentProject.pdb: Cannot find or open the PDB file.
What's odd about this is that C:\solution\ is the folder location in the Docker Container, not on my local drive. C:\solution\ is a mounted volume in my container and it mounts to C:\source\reponame\ on my computer, so I guess this is why the PDB file can not be found...
So my questions are...
Why is VS2022 looking at C:\solution\ not C:\source\reponame\ (or some how retrieving the DLLs the same way as VS2019)
and
Is there a way to have VS2022 look in the correct location? (I don't really want to add a Symbol Path to VS for each project I work on, especially as these could change).
Cheers,
Dan
I have just bought a new development machine and have taken the latest version of the source code of a project we are working on but when I try to debug it I get the following error:
Could not load file or assembly 'Business' or one of its dependencies. The process cannot access the file because it is being used by another process. (Exception from HRESULT: 0x80070020)
"Business" is a class library project in the solution so it's unusual that it cannot load this assembly.
I've spent quite a big of time this morning double checking that the assembly references in both projects are targeting the same versions and they are.
The new machine had Panda Anvirus Free version installed. Although no errors were reported by it, it was interfering with the debug session. Once it was disabled the application started to work.
Once Panda AV was uninstalled the problem was no more. Hope this helps someone else that encounters the same issue!
When I build my app, I just get a single bin folder, with all files in it, versus the usual bin\debug and bin\release folders. Why is this?
Because the website can be run by IIS ( and the various flavours of... ) in the location you built.
IIS expects the assemblies in the bin folder ( it's hard wired in the AppDomain setup ) so the web project type compile to this location.
For an interview, i was put across with this question. One of the link could be this which answers in brief .
The above link will give you the statement as below:-
Release Mode
When an assembly is built in release mode, the compiler performs all
available optimisations to ensure that the outputted executables and
libraries execute as efficiently as possible. This mode should be used
for completed and tested software that is to be released to end-users.
The drawback of release mode is that whilst the generated code is
usually faster and smaller, it is not accessible to debugging tools.
Debug Mode
Debug mode is used whilst developing software. When an assembly is
compiled in debug mode, additional symbolic information is embedded
and the code is not optimised. This means that the output of the
compiler is generally larger, slower and less efficient. However, a
debugger can be attached to the running program to allow the code to
be stepped through whilst monitoring the values of internal variables.
[Update] After little google i came across similar question- "Confused about Release/Debug folders in Visual Studio 2010" with same answer which i have quoted above.
Also, please look into why-have-separate-debug-and-release-folders-in-visual-studio. #riko and other members of Stackoverflow have answered quiet well..
This behavior is not specific to MVC4. In fact it is consistent with so-called "classic" ASP.Net, both Web Site projects and Web Applications.
The distinction between release and debug modes in ASP.Net is that Release builds need to be Published.
I'm developing an ASP.NET MVC (still v2) Azure web application. I've run into a problem that seems to require me to step through the MVC code itself. I can do this but also need to be able to inspect the code as I step, so I need to be an unoptimized version (so as to not get the "Cannot obtain value of local or argument ...") message in the debugger.
The standard way of circumventing the optimizations (http://blogs.msdn.com/b/sburke/archive/2008/01/29/how-to-disable-optimizations-when-debugging-reference-source.aspx) doesn't seem applicable to running in the Compute Emulator.
I also tried this by creating a local debug build of the System.Web.Mvc project but my web role hangs when I try to start it in the Compute Emulator.
So ... Any help with either of the following would be much appreciated:
Running an Azure web app in Visual Studio (2010) so that it will ignore code optimizations in system dlls.
OR
Creating a local system debug build so that it can be referenced by an Azure web app being debugged in the Compute Emulator.
If the Azure Compute Emulator is giving you issues you could run your MVC project using IIS Express. Just right click and and Select Debug/Start New Instance.
I was finally able to get unoptimized ASP.NET code while debugging in the compute emulator. The basic approach described on MSDN (http://msdn.microsoft.com/en-us/library/9dd8z24x%28v=vs.100%29.aspx) and elsewhere (http://martin.bz/blog/asp-net-mvc-source-debugging-the-easy-way among others) is to put an .ini file that tells the JIT compiler not to optimize in the same directory as the DLL.
The first challenge was to determine just where that was; it finally dawned on me to watch the logs in the Compute Emulator UI and see where they loaded the DLL (in this case System.Web.Mvc) from.
The second challenge was getting the .ini file there. Windows Explorer didn't work because it uses a different way of viewing assembly caches that doesn't give you direct access to the files. One of the posts I read reminded me that using the Command Prompt might give me that access and it did. The last step was realizing, when the Command Prompt wouldn't permit me to move the .ini file into the assembly directory, that I needed to run Command Prompt as admin.
Once I could view variables while debugging, I pretty quickly realized where my bug was.
We just set up TFS 11 for the first time. Running a gated check in, it succeeds but returns this message:
'srctool.exe' returned an unexpected exit code: '-1'. An error
occurred when opening a file "CustomDllName.dll": Assembly
"CustomDllName.dll" is not a valid .NET assembly and will be skipped
for analysis.
Well, it's right: that file is a legacy Visual Basic 6 DLL that we don't have much control over. It's included in the project for COM access to some of the methods.
Is there a way to instruct srctool.exe/TFS to skip that file when doing the inspection? Or another way to attack this?
Here is the solution that ultimately worked for me
A member of the TFS 11 team at Microsoft mentioned to me that the problem is due to a change in behavior that the Windows 8 team made to the srctool.exe tool.
By copying this file from the Windows 7 SDK (WinDBG) toolkit and overriding the one included in TFS 11 Beta, I was able to successfully run a build without any errors.
Is this a srctool.exe error from the shipped IndexSources activity? srctool.exe in this activity does one thing, which is to list the source files information in the pdb. I am not a srctool expert so I don't know why it fails in this case. I do know that srctool.exe has some behavioral changes in version 11, most of those are fixes from the previous version.
There is a workaround which requires udpating the build template. It is not very nice but it works. Srctool.exe is run (inside IndexSources activity) for each pdb file in the SymbolFiles collection. Now that you know which pdb fails, you can update the build template to add a RemoveFromCollection activity before the IndexSources activity that remove the troubled pdb from the SymbolFiles collection. This is by far the most straightforward workaround I can think of.
Alternatively, you can edit FindMatchingFiles activity's search pattern to exclude the pdb files you don't want to have sources indexed.
Based on the error message you got, it doesn't seem to be related to the known issue Ed mentioned. We fixed this issue for the next release, so if it's related, it should be fixed :-)
Let me know if you have any issue with VS11 Beta around the build templates.
Thanks.