I used Dotfuscator to protect my application from reverse engineering I encrepted the dll files and saved them, my question is what to do after that? how to use new dlls insted of old ones because when i do copy and past and after that I publish the website it get the old dlls not new ones?
Are you publishing your site via Visual Studio? If so, it would seem that the obfuscated DLLs are somehow bypassed. Are you overwriting the original DLLs with the obfuscated DLLs before publishing them? As a last resort, use FTP to publish your site, as you can be sure which versions of DLLs you're uploading.
Related
Backgroud:
I am in the process of migrating a console application to be part of our existing web API project. All development work is done on Visual Studiod 2015 (with IIS Express). The application uses few third party datasource api DLLs to grab data from that datasource. All these DLLs are managed by our internal nuget package sources.
Issue:
Now the console application runs fine and can load up the those DLLs. I copied across the logic into my web project and added the DLLs via nuget. Solution builds but got the following error when starting up the web project:
Could not load file or assembly 'ABC.DLL' or one of its dependencies. The specified module could not be found.
Where ABC.DLL is one of the third party DLLs.
I have done the following:
Confirm ABC.DLL is in the bin folder of my web project
Changed target build platform of my web project to be x86 and unchecked "Use 64 bit version of IIS Express for websites and project" setting in VS2015 (the third party dll is 32-bit)
Ran dumpbin.exe on ABC.DLL's dependency and got XYZ.dll,MSVCR120.dll,KERNEL32.dll,MSVCP120.dll,mscoree.dll
Regarding to the last step, those dlls were all missing in the bin folder (but the last 4 DLLs should be in system32 win directory so shouldn't matter?)
As for XYZ.dll, it is another third party library and is located on C:\Program Files (x86)\XYZ\ folder. I manually copied it across to the web project bin folder (in fact copied across all Dlls inside XYZ folder) and still get the same issue.
Questions
What am I missing here? The console app obviously can load ABC.DLL but the web project can't. Appreciate it if you can tell me what to check next.
The error message from start up web page is not very useful, is there a way to find out where the web project is trying to load the third party DLLs?
Thank you in advance!
Simply adding external DLLs to your Bin folder is not a great idea. Files can disappear from this folder for various reasons, such as your team members deleting a seemingly useless DLL, or through Visual Studio clearing it. Also, the output DLLs from referenced projects in your solution, would end up there, and are replaced every time you build your project.
What you should do for third-party DLLs, is create some "dependencies" folder in, or close to, your project, and stick the DLLs in there. Then you should right-click on the project, select Add Reference, browse to that new "dependencies" folder, and add a reference to the DLL that way. This is similar to the way NuGet works; it keeps DLLs in their respective folders inside the packages folder, and adds references to those DLLs.
I finally found the issue and thanks for all the help, I had to disable shadow copying in VS (mentioned in 64 bit managed assembly with unmanaged dependencies not loading in IIS / ASP.NET MVC 4).
The best way to include System.Net.Http.Formatting might be through nuget. But when a developer sees it in the default Assemblies section in reference manager then they just add it, expecting all developers to have it installed by default. But to our surprise, some developer machines did not have this dll.
All developers have the correct folder where this dlls is found
"C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4\Assemblies\"
Some developers just have XML files and others have dlls in it, even though the file names are the same.
Why are dlls missing in some machines?
Sometimes it is really an issue while finding the missing dlls. Better approach is to clean the nuget cache and folder both and restoring nuget packages again would resolve this issue.
System.Net.Http.Formatting mystery resolved
System.Net.Http.Formatting won't be installed by default along with asp.net. If it appeared in one developer machine, then it could be because some other projects in the VS might have used a nuget to pull it in. This developer without knowing this gives a manual reference to this dll in a new/different project. To him/her everything works fine.
When another/new developer comes and tries to do the same in his/her machine, before reaching this particular project(which pulled in System.Net.Http.Formatting through nuget), the developer gets error(from the manually entered dll project by the previous developer mentioned above). That explains why the dll is missing in his/her machine.
But why is XML file present then?
Becuase the package folder was stored in tfs/git from the first developer machine(who successfully had the dll through nuget). And tfs/git ignored the dll when checked-in.
An episerver installation puts the episerver assemblies in the GAC, I see them with C:/windows/assembly.
Besides, all the episerver dll's are present in C:/Program files/Episerver after an episerver installation.
When a create an episerver project via the episerver deployment center or with Visual Studio 2010 using the episerver template, I see that the bin-folder of the newly created project contains a lot of episerver-dlls, which is not very surprising. And I suppose that they are copied from C:/Program files/. If I open the project in visual studio, I see that it's those dll's that are referenced and not the ones from the GAC or from C:/program files/episerver.
Well, all of this is very confusing.
Why is Episerver putting dll's in the gac and not referencing them? What is the best way to handle references to episerver dll's for development in a team?
Moreover, IF episerver would reference the ddl's from the GAC, how would I see that in VS. I mean, what would the properties of the reference be?
Basically, this is all just episerver deployments decisions. I'll try and go over every your question one by one:
Putting dlls into GAC is useful when you want your users to access dlls in the reference dialog from ".NET Framework" tab. Suppose you're creating simple project (not episerver one) and want to add episerver dlls. Instead of looking for them on the hard drive you reference ones that are pointed from the GAC. That's easy for development.
Why not reference GAC dlls ? It's to easier deploy your solution with the dlls. Suppose you're deploying your solution to the server. Server won't be having episerver dlls in the GAC (and shouldn't have, anyway). So they're probably setting "copy local = true" property to copy the dlls into the output folder, making your solution portable. Also, the GAC assemblies aren't "referenced" - GAC just contains copies in a case of need and a reference is added to the "program files" folder with the dlls.
Best way for a development team is to use GAC or to define some kind of "Third Party"("externals") folder in the repository and put your dlls there (and reference from there). First approach requires episerver install on every dev machine, second uses up some space in your repository.
As GAC assemblies can't be referenced (they actually can be, but it's a headache), there is virtually no difference between the result - different paths only.
We usually create a separate directory where we store all .dll-files and reference them from that directory. This means all third party-librarys and episerver-dlls.
The biggest reason for doing this is to avoid a hassle when a new developer needs to setup the project, and also to avoid conflicts between different versions when referencing from GAC.
I am working with Team Foundation Server and Visual Studio 2008 for the first time. I had a web site project that was done with Visual Web Developer Express, which I have converted to a solution containing a Web Application Project, setup for TFS source control, etc etc.
TFS was having issues checking in/uploading some of my referenced DDLs, specifically AjaxControlToolKit, saying things like /bin/AjaxControlToolKit.pdb couldn't be found. I removed the reference, deleted everything it had in /bin (it had created lots of folders like /ar, /cs, /de, etc etc along with other files like /bin/AjaxControlTookKit.dll), then re-added the reference to AjaxControlToolKit. It will now upload, and works fine locally, but it didn't re-create anything in /bin. I have other references that work fine and have info in /bin (ie: /References/LinqKit.dll and /bin/LinqKit.dll) I cannot do a build on the server yet, but locally it works. So, will this work when its built on the server? Why didn't it recreate anything in the /bin folder? Is that something to do with Visual Web Developer Web Site vs Visual Studio Web Application/Solution? Any info is appreciated! Thanks.
References are references, not copies of the assemblies. Where are the assemblies you're trying to work with?
Typically, you'll want to check in third-party assemblies that you are not maintaining source. You'll then want to change the file references to point to the version from source control.
Of course, this means that all your developers and build machines will need to maintain the same folder structure on disk.
I have a web site project with a lot of files, it has become really slow to build. What I want to do is to create a web application project, and in Explorer add all the files to it, including the Bin folder. In Visual Studio I will not add these files (Show All Files will show them), only new files in one new folder that I am going to work on.
There are several assemblies in the original Bin folder that I need to reference in the web application project. Also, I will include the original web.config file.
So what way am I going to regret this in a few days?
You wont have support for all the old stuff when using the Visual Studio Publish feature (I assume you wouldn't anyways).
I also would assume you wont have access to what is in your App_Code from your new web application project.
I will add an answer myself.
A rebuild in Visual Studio will clean out the bin folder...