probably this is an easy one.
I have a solution that contains two projects:
a web page (asp.net)
a project that contains logic (Project B)
I am set up the web in a server and it loads ok, but when it needs to use the Project B I get an exception showing that it is searching a class in the path of the machine where the code was compiled. This image is the exception I am getting (in orange the path of the compilation machine):
How can I configure the web in order to tell where to search the files of Project B?
Really appreciate any help
I get an exception showing that it is searching a class in the path
of the machine where the code was compiled.
Wrong! C# compiles to intermediate language (IL) and this last one is the executable code which is also compiled to machine code using the JIT compiler or NGen-ing the IL..
You find that class file path because you're publishing your Web app using the Debug configuration and you're also including the .pdb files.
While I find that part of your question is a possible duplicate (see my close vote comment in the question itself), I wanted to add an answer to demystify your statement:
How can I configure the web in order to tell where to search the files
of Project B?
In .NET, executable code is compiled into assemblies, either executable or dynamically-linked libraries (DLL). That is, these class paths to your actual code location in your machine are just debugging information to make your life easier when looking and finding issues during some execution call stack.
The files names are from whatever machine the .pdb file for your assembly was generated on.
From MSDN:
A program database (PDB) file holds debugging and project state information that allows incremental linking of a Debug configuration of your program
Your problem looks like a database connection issue (which is explicitly said in the exception). Please check your connection string and make sure that your database is accessible.
Related
There is a c# Application that compiles C# code stored in DB and creates a DLL in memory using roslyn compiler that the DLL is loaded in memory and an instance of the type is created from the following code
Activator.CreateInstance(type); // Just creates an instance of the type so that any public method or property can be accessed
The reason for having the code in DB is abit complex to explain here for the scope of the question but it is important to note there is no physical file where C# code is present.
Also please note the DLL is created at runtime by the application in release mode or debug mode depending if #ifdebug is true or not.
Now what we want is if the application is running in debug mode we should be able to debug the DLL created in runtime. Can experts over here help me to give pointers how to achieve it. Since access to code is there from DB we can in runtime create a temporary file in some temporary location if the application is running in debug mode but how do we let Visual studio know we want to link the specific DLL to this temporary C# file for the purpose of debugging. Please note the DLL is in memory in some concurrent bag and we arent creating PDB file too
Any pointers will be helpful We are using Visual studio 2022
This is possible in Visual Studio 2022!
Follow the guidance of emitting the portable PDB from this answer. Since you didn't show much of how you are compiling, I will assume it's pretty close to that and getting the source code emitted won't be a problem.
When the assembly is finally loaded into the program, VS2022 will automatically pick up the symbols. You can verify this by looking for a your named DLL in the Modules window. Ctrl+Alt+U or Tools>Windows>Modules. From the answer I posted, it will be randomly named.
When you have the program running, the external sources node (which is new with VS2022) will show that same random DLL name.
If you open the generated file, you should see your generated code. You are also able to place breakpoints in this file!
Not sure if it matters or not, but in my VS options I have disabled "Just My Code".
I'm not sure if this is possible with Visiual Studio but maybe you could have some luck with dnSpy:
https://github.com/dnSpy/dnSpy
I was able to debug a dll that was loaded by a program at runtime using:
System.Runtime.Loader.AssemblyLoadContext.Default.LoadFromAssemblyPath(path);
so maybe it can help you too.
I've just inherited a web application whose source has long been lost (originally written in 2010 and shelved). The application has a few .dll assemblies that related to the application itself e.g. "applicationCORE.dll", "applicationBI.dll", "applicationDATA.dll" and "application.dll"
I've seen this question and the suggested tool (Just Decompile) is brilliant and created a .sln and .csproj file for the first assembly that I decompiled. My question is how do I merge the various projects that would be created through decompiling with the compiled web application files (.aspx) also, how do I resolve the references in the .aspx files i.e. referencing the codebehind file that no longer exists e.g. "default.aspx" references "default.aspx.cs" while the decompiler creates a "default.cs" file. Is it safer to rename the .cs file or should I update the reference?
Finally, will each dll appear as a separate project within the solution?
I realise this may be perceived as a duplicate question however there doesn't appear to be a resource online that walks a developer through the process.
Following David's advice, I managed to get the application running from decompiled assemblies. Here's the process I followed to get it working
I had already decompiled the various assemblies into projects using a Reflector (on a trial).
I created a blank Web forms application in Visual Studio
I added the .aspx pages from the website to the project through visual studio
Then added the .cs files from the decompiled 'application.dll' project (since this is the website project within the solution. Some files had to be renamed to match the codebehind references in the `.aspx. files
Each additional project e.g. applicationCore.dll was then added to the solution
Each project's references needed to be updated and references to the newly added projects must be added to the startup project
Since the website was built so long ago, there were 1,000's of syntax errors. The easiest way to resolve them was to use Notepad++ and the Find and Replace. To be safe, I did this file-by-file by following the errors from Visual Studio rather than a batch find and replace
When trying to build I noticed errors where required assemblies were missing so I changed the build output directory of the sub-projects to the bin folder of the web project
I added the connection strings and settings from the original website's web.config. I did this line by line to make sure I didn't break anything and so that I could trace the result of each addition
Finally I had a successful build!
Additional Steps
There were also syntax errors which I assumed were due to the decompiling process. Some external references needed to be added and there were slight changes due to the age of the project e.g. asp:AjaxScriptControl changed to asp:ScriptControl (after adding the package using Nuget). I also had to install Crystal Reports for this application and will have to purchase a Telerik licence as there are UI components being used (although I'll see if I can use an open / native alternative as I work through the app).
I've logged in using credentials (I did have to set the correct start page) and tried a few basic CRUD operations. There are silly issues that have to be resolved e.g. the authentication doesn't work properly and there's no redirect if you access a protected page but these things are relatively minor compared to the issues I faced initially.
What I must say is each error was resolved using questions and answers from this site! This was all completed in just under 6 hours.
I am using VS2008 and an AddIn to create a web service.
The tool also creates code to access remote procedures (in fact this is another web service).
In the created code some classes are used which will contain the response. So it is a very nice solution.
Now to my problem: When I use 'Goto definition' function, it shows me the class 'extracted from metadata'. So I guess it compiled the class into some library.
Now I would like to know the DLL where the class is defined.
How can this be achieved? To be honest, I manually checked the DLL and either I am getting old or there is some magic in how VS locates classes.
Could someone please give me a kick/hint in the right direction?
Thanks
Ok. I found out myself. It is too easy:
First, I hover the cursor over the tab header and it gives me the location of the DLL. Although this DLL is not part of the project, within the .svc file, the class is known as the declaring DLL is in the bin folder of the web service project.
I find this very strange as I thought that only files being part of the project (i.e. included) or libaries in the GAC are used for name resolving.
Anyway, I learned something new today, which is not part as all.
I have a problem with getting above exception. I have a relatively simple structure separate in two dll.
First one contains a IEntityService, IEntity, with basic implementation. Second one contains the actual implementations as well as interfaces. so there is a IMachine service which implements IEntityService and MachineService which implements both IEntityService and EntityService. Similar situation happen for a Result collection( entity plus service). Additionally the service(Machine and result) are partial classes/interfaces where one of the class is auto generated.
Now in one of the ResultMachine I am trying to get a machine and in a case it do not exists I am creating it and saving. However when I am trying to save I got the "Method not found" when trying to access a saving method from a EntityService class. However if I wrap EntityService.Save method in a MachineService it is working without any exception.
Edited:
The code is not required. THe resolution was to re-link the reference. What was misleading for me that my dll is not in GAC, it is linked with VS. What is more it is not strongly signed, the only difference is version number.
We have got this error a few times, you can recreate the problem as follows:
Created project with 2 dll's (say a program dll and a test dll)
deploy program dll to GAC
Add new method
Create test to test the new method
build solution
run test (not in debug mode)
You will now get the method missing exception. The reason is that it is using the old version of the dll that is in GAC and does not have the method.
Some times it uses a cached version of the old dll, IISreset can help.
In your case check for any old versions of the dll.
My first instinct would be to check to make sure the assemblies contained the classes with the missing method. I suppose its possible that the assembly didn't get updated immediately?
When referencing the "same" type from different assemblies, make sure you are loading everything via the same path. Otherwise, identical types can actually be treated as if they are different.
See this article for more: Fusion Loader Contexts - Unable to cast object of type 'Whatever' to type 'Whatever'
This happened to me when I went in and tweaked my build settings to output to /bin/Debug rather than to just /bin in a case when I was also using IIS to host the site from the dev folder.
You need to have the binaries in the same folder as the service, in my case, and the tweak left old versions in the bin folder and put subsequent builds into the /bin/Debug folder (and /bin/Release).
Either keep the settings as is and have a post build action to copy the bits up one level, have different IIS applications for debug/release, or deploy to another folder altogether. The latter is probably most "correct" but for my purposes I just realized after much wheel-spinning, that I had different versions in the service's folder. HTH.
In my case I just deployed on a machine with .NET 3.0 (Windows XP) while the compile target has been .NET 3.5.
This error message is really not helpful.
Problem has been usage of DataContract from System.Runtime.Serialisation.
I have a project that imports a DLL (written by me). Sometimes when an exception is raised within a method in the DLL, the host project opens a tab and let me see the code within the DLL. I can also put breakpoints within it.
But this behavior seems quite random, I cannot have it on purpose and not always works. Plus, I can't see the file name in the project explorer window.
Any help on debugging DLLs? Thanks
The enhanced debugging (for a dll not in the current solution) depends largely on whether you have the debugging symbols file (.pdb) in an obvious location - in particular, next to the dll itself. You can also load symbols manually from the modules window (when debugging, Debug -> Windows -> Module, right-click, Load Symbols From...)
What may be getting in your way here is a feature known as Just My Code (JMC). This is a debugger / CLR feature designed at limiting a users view of the world to just the code that they've written. The various ways in how a piece of code or DLL is determined to be yours or not can be confusing at times.
Next time you hit this problem, try disabling JMC and see if it fixes your problem
Navigate: Tools -> Options
Navigate: Debugger -> General
Uncheck the Just My Code option
On the managed C# program that calls the C++ dll,
right-click properties
debug tab
Tick Enable unmanaged code debugging
Hope this helps,
Tony.
To debug a dll it must have the pdb file with the debugging information that matches that dll.
Visual studio uses the .Pdb symbols generated by the compile process to enable you the dev to peek at the source when an exception occurs.
This information exists for two reasons. The first reason is for the compiler (i.e., a program that turns source code into an application, such as an .exe or .dll file) to use when it builds the application. The second reason is for people to use when debugging an application. The symbolic information is generated as part of the compilation of an application (if you set the compiler to generate symbolic information). This information can reside directly in the application files, or it can be written to separate symbol files. Where the symbols reside depends on your development application and the settings you choose. For example, Microsoft Visual Basic (VB) builds symbols right into the program files. Visual C++ (VC++) usually builds one or two separate files.
Symbol files have two file types—.dbg and .pdb. The .dbg files are in Common Object File Format (COFF), which is a generic symbol file description that doesn't include source line information; many debuggers can read these files. The .pdb files are a Microsoft format and contain a lot more information than the .dbg files. For example, source line information is available only in .pdb symbols. Symbol files that include source-code line information let you use the source code for debugging.
While it doesn't allow you to debug the code, Reflector is very useful when it comes to inspecting a DLL. The combination of a Stack Trace, the offending DLL and reflector will often get you to the nub of the problem.