I already did the process - Importing dll file in Dotpeek and Exporting Assembly to Project, Now I can modify dll file in VS 2015, but how to recompile the project and use recompiled dll file again in existing project.. I tried with building project in vs 2015 but it displays lots of compile time errors, Please help
Thanks :)
Rather unfortunately, there is no decompiler that will produce code that compiles for an assembly containing more than a couple of classes.
So you might want to try JustDecompile + Reflexil to do your edit. The advantage of this approach is that only the part you edit will get changed and the rest of the assembly will remain the same as original.
You can use dotPeek of Jetbrains, can open any DLL with it by just right-clicking the DLL and Open with dotPeek.
Once DLL is de-compile in dotPeek, right-click click on the DLL in the left sectoin and chose the option Export to Project.
It will open the entire DLL as a Class Library Project in Visual Studio in the case of .NET DLL.
You can modify the source code and recompile the DLLs.
I am not very sure about your requirement, I would advise you to Extend the DLLs method/operation into your project rather than doing an edit on the recompile on the DLL.
Related
I cannot find the dlls. Visual Studio does not tell you where they are stored. I want to load them into .net Reflector.
I know this is an old question, but if you're looking for these then check out the following location...
C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App
Under there should be versions of .NET Core, and these are the runtime assemblies you'll need to load in Refelctor to see the source code.
Note - if you use an assembly reference from within Visual Studio (by maybe clicking F12 on a .NET Core datatype or interface), that will show the reference assembly and not the implementation assembly.
As an example, hitting F12 on ControllerBase gives me this...
C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\3.1.0\ref\netcoreapp3.1\
Microsoft.AspNetCore.Mvc.Core.dll
This is not the runtime assembly you need when using Reflector. GitHub is all fair and good for finding source code to one method, but you can't beat Reflector when you want to move between different classes in different files so as to work through an implementation pathway.
Hope this helps!
You can set them up I properties. They are still in the bin folder once the code is compiled. Although if you are planning on using the dll directly you can publish then first
I have a project that I am developing that uses a third party COM library as a reference and I would like to build this project on a Visual Studio Team Services build client. My first idea is to create a MSBuild task that checks to see if the COM library is installed on the local computer and if it is not, go ahead and install it, but this seems like a really messy way to do this. I have searched around but it seems as though all the answers date back years and I can't seem to make the few I have found work in a VS 2013 project. How have other people solved this problem? Is there a cleaner way?
For reference I have also tried this solution, which looks really clean, to no avail.
I would go one of these routes:
Generate interop dll with tlbimp, add it to your project and reference it directly:
In VS command prompt, execute tlbimp.exe <your_dll> to generate the interop dll. You can specify the name with /out option.
put this dll somewhere with your code
reference it by going to Add reference > Browse and click Browse... to add the dll
Generate the tlb from COM dll , add it to the project and reference the tlb:
Generate the tlb (e.g. using OLE/COM Object viewer) or extract it from the dll resources,
put this tlb somewhere with your code
reference it by going to Add reference > COM and click Browse... to add the tlb reference to project
As #HansPassant noted in comments, this solution still relies on registry, but you can register it with regtlb, regtlib or similar tool, as a prebuild step, which should be easier than installing the server (though if it is just a dll, you could use regsvr32 to register it instead of full install). However, this is still more complex than the approach with interop dll
I have been working on a few different applications and I want them all to share the same DLL library. The shared DLL is one that I created, so really I want each application to have a dependency on the DLL so that the DLL gets built in the same solution as the application. Then the DLL should copy itself to the application's bin folder before the application runs.
After figuring out how to do this, it seems that it should have only taken about 5 minutes, but unfortunately it took me an hour to figure out. That's partly because similar questions were referring to older versions of Visual Studio, or referring to 3rd party DLLs. So I thought I'd post the steps here.
You should already have one existing project and solution for your DLL. Open your solution for your new application that depends on your DLL
Highlight the top line in your Solution Explorer (your solution name), then go to the File menu and choose Add > Existing Project...
Browse to the project file for your DLL and select it. That will add the DLL project to your solution
Although your projects are now in the same solution, that didn't actually create a reference for your main project. So now right-click on your original project (should be 2nd line in your Solution Explorer) and choose Add > Reference...
The Reference Manager will appear. Be sure that you have Solution > Projects selected on the left. Then you should see your DLL project listed on the right. When you hover over it, a checkbox will appear. Select the check box. Click OK.
Last, be sure that your Project Dependencies are set correctly. Again, right-click on your Solution in Solution Explorer (top line). Choose Project Dependencies...
In the Projects drop down, make sure your main project is selected. Then in the Depends On list below, check the box for your DLL project.
Now when you Build your solution, it will first build the DLL, then copy it to your applications bin folder, then build your application. The Reference will also allow you to refer to the DLL in your code files, for example with "using MyLib;" for C#, or "Imports MyLib" for VB
Now when you Build your solution, it will first build the DLL, then copy it to your applications bin folder, then build your application.
Thank you for explaining this. I did all the steps (Visual Studio 2015) and I noticed that "Build solution" command builds all the DLLs, but it does not copy them to the right bin folder. To achieve that I need to build the active project (right-click on the active project, then "Build").
Say, that we have .NET application App along with additional assembly ClassLibrary, which, in turn, uses native DLL called Library. All these are in single solution, so I may set up the dependencies etc.
The catch is, that I want the Library to be automatically "attached" to ClassLibrary, such that when my App references it, Visual Studio will automatically copy the Library to target bin folder.
Usually I did that by using pre-build or post-build events and adding custom scripts. But hey, all these are in the same solution. Is there simpler way to keep such native-dll-reference for .NET assembly?
You have to add the native library to your project. If the native library is in the Solution (not in the project) than it is there only for your reference. You have to add the native library to the Project because the project file describe the build behaviour.
Than add native assembly to the ClassLibrary project and then in properties set: Copy To Output Directory to Copy if newer or Copy always.
Is there any way in VB.NET to DllImport a dll file from the resources?
I really don't want to add the dll with the executable path.
You can embed a DLL into an executable:
Jeffrey Richter: Excerpt #2 from CLR via C#, Third Edition
Many applications consist of an EXE file that depends on many DLL
files. When deploying this application, all the files must be
deployed. However, there is a technique that you can use to deploy
just a single EXE file. First, identify all the DLL files that your
EXE file depends on that do not ship as part of the Microsoft .NET
Framework itself. Then add these DLLs to your Visual Studio project.
For each DLL file you add, display its properties and change its
“Build Action” to “Embedded Resource.” This causes the C# compiler to
embed the DLL file(s) into your EXE file, and you can deploy this one
EXE file.
At runtime, the CLR won’t be able to find the dependent DLL
assemblies, which is a problem. To fix this, when your application
initializes, register a callback method with the AppDomain’s
ResolveAssembly event.