I know this is a wacky question, but in Visual Studio 2010 C#.Net is there a way to name an Assembly with a different extension than DLL. E.g., MyAssembly.MLL instead of MyAssembly.DLL.
I poked around but could not find a way to do it.
No, I don't believe so - at least not without a bunch of extra work.
I've just tried this with a manual rename step, and although you can compile against a renamed assembly, it won't be found at execution time. The code will contain a reference to MyAssembly, and the runtime will try to resolve that to MyAssembly.dll and MyAssembly.exe... but it won't know the actual filename you used. It's possible that there's a way of configuring this within app.config or using AppDomain.AssemblyResolve to resolve the assembly yourself - but I strongly suspect other things may break.
Aside from anything else, I would discourage you from doing this just in terms of unconventionality. You'll surprise other developers, tools etc - not a good idea.
Related
I managed to decompile a c# file (using dotpeek) and I want to edit a couple of simple things (using visual studio).
The problem is this file has many dll dependencies even though the edits are necessary only on the main exe.
Obviously if you try to build an exe on vs without having the references and dependencies in place the compiler will complain. Are there any solutions to this?
You cannot build without the dependencies; however, there is no need to decompile the dependencies. Just add the DLLs themselves as reference to the project.
This is always fine if the decompiled assembly depends on other DLLs; however, if the other DLLs depend on the decompiled assembly, this will only work if the assemblies are not signed, i.e. if they are not using strong names. The purpose of signing is precisely to disallow such hacks.
No, you can't build without the dependencies because the compiler has to check that types match and have the indicated members etc.
When I run unit testing to serialize to an xml file, I keep getting error message:
Could not load file or assembly
'Company.Fin.Bank.Common.XmlSerializers.dll, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The
system cannot find the file specified.
I guess Company.Fin.Bank.Common.XmlSerializers.dll may be in cache somewhere but it is impossible to find this dll, even though i don't need that dll. I want to remove it. But where can i find it? is it possibly in a cache? if yes how can i clean the cache from VS? This problem is very new to me.
What a weird part is that i used another laptop (win 7) to run the unit testing, there is no error message i got - it worked. but when i used my own laptop (win 8) i keep getting error message. I have no idea why.
I hope to find solution from you. Your help means alot. Thanks!!!
That assembly is dynamically generated by the framework (XMLSerializer)
In .Net implementation, the XmlSerializer generates a temporary
assembly for serializing/deserializing your classes (for performance
reasons).
Also, this may be normal behavior - is it stopping your application from running?
even though i don't need that dll
Visual Studio will usually remove unneeded DLLs. Typically this is caused by dependencies (which are harder to keep track of).
I want to remove it.
Check in the References of the project in the Solution Explorer. If any of them have a yellow triangle that means they can't be found (the project may still compile and run if you aren't actually using that reference).
is it possibly in a cache?
As Daniel Kelley mentioned C:\Windows\assembly and C:\Windows\Microsoft.NET\assembly are where the global assembly cache is located. If it isn't there check the Hint Path of the reference (it will show up in Properties).
Good luck finding your reference, keep in mind that you need not only the actual DLL but all of its used references in most cases. Also a decompiler like DotPeek can be useful if you need a more discreet way of looking at references.
Basically, I developped a small library with some common fonctionnalities that I use in all my projects. For some political reasons, I cannot choose a generic name for that library (including namespace and assembly name). Usually, it must include the name of the enterprise, something like this for the namespace: Enterprise.ProjectName.XXX.YYY.
For the moment, I'm doing a copy of my library, then I'm renaming the namespaces manually with Visual Studio, and finally I'm recompiling the whole thing.
So my question is the following: Is it possible to create a small program that takes an assembly as input, rename all namespaces from MyLibrary.XXX.YYY to Enterprise.ProjectName.XXX.YYY as well as the assembly name?
What are the steps to follow?
[Edit]
Generating the assembly automatically seems to much work. I will use resharper and/or CTRL+ALT+F like I did so far. Thanks for the answers...
You could use Mono's Cecil project to disassemble the assembly, inspect each type, rename or recreate the type with a new namespace, and generate the resulting assembly.
That being said, it might be simpler to use a tool like Resharper which allows you to rename namespaces correctly within the code base.
Some options:
If you are copying the entire source code for your library into your new project, you can use a refactoring tool like Resharper to "Adjust Namespaces". This is a pretty quick and safe refactoring.
If you just need to avoid shipping the internally named assembly, you may be able to use ILMerge to 'hide' the internal assembly during a post-build step. This is viable if it's just a perception issue for the final assembly names in the binary output directory.
Deal with the issue at the political level by describing your internal library as being no different from any other third-party dependency. Then the naming is no longer a problem. This may solve other problems if you're shipping the source code of this library to multiple clients, as it clarifies that you are not giving full ownership of your 'shared' code to each client. Otherwise they could potentially argue that you are not allowed to use that 'shared' code in projects for other clients, since it is clearly owned by them, having their enterprise name in the namespace.
So I'm trying to obfuscate my program AFTER it's been compiled. I'm pretty sure that's how you do it (?)
I'm using a pretty popular freeware called EazFuscator which has a nice little command line utility.
So if I go:
Eazfuscator.NET MyProgram.exe
it'll obfuscate it successfully, and when it's done, I'll try to run my program and it crashes! (gives me some runtime exception)
Another thing I tried instead is to obfuscate one of the DLL's my program uses:
EazFuscator.NET SomeDLLMyProgramUses.dll
it'll obfuscate it successfully, but again, when I run my program crashes...
I'm wondering first off, regardless of this EazFuscator program, is it possible to obfuscate .DLL and .EXE files? and is it usually NOT supposed to break them?
Note: I do have some reflection going on in my program, and maybe that's whats causing the problem.. but I'm not 100% sure.
There is Dotfuscator community edition, which you could try.
In general obfuscators are not supposed to break the apps they obfuscate. You should contact the manufacturer if you can reproduce the issue.
Most of the Obfuscation tools have settings that allow you to manage the level of obfuscation - like type names, method names, strings and so on. It is possible that your level of obfuscation has resulted in an IL code that is broken due to these changes that the tool performed on your original IL code. Check the settings available and attempt to avoid a few of those settings.
If you are using reflection then the obfuscation tool will probably break you code. During obfuscation type names are usually changed, therefore your reflection may not work as expected, especially if you are referring to a type by name. Use a tool like reflector to have a look at you obfuscated assembly, you will be able to see whats going on.
Yes, we need to obfuscate our assembly after compilation. Assembly is built again by obfuscator. So we don't need to worry about compilation and building it.
I am using FxProtect which is free obfuscator. Advance Professional version is also available but it is not free. You can try it...
.Net Obfuscator
No, you do not typically obsfucate your executable program. I'm sure you've been thinking about it since you posted your question and can imagine why.
Run the obfuscation on your source code then compile that into deliverable.
Whether or not your code is broken by obfuscation depends upon what you do in your code. If you're using reflection in there that will almost certainly be the root cause.
CLISecure has worked well for me in the past (even on mixed-mode assemblies) ...but we don't use any reflection in our codebase.
My C# project - we'll call it the SuperUI - used to make use of a class from an external assembly. Now it doesn't, but the compiler won't let me build the project without the assembly reference in place. Let me elaborate.
This project used to throw and catch a custom exception class - the SuperException - which was derived from the standard System.Exception and lived in a separate, precompiled assembly, SuperAssembly.DLL, which I referenced.
Eventually, I decided this was a pointless exercise and replaced all SuperExceptions with a System.SuitableStandardException in each case. I removed the reference to SuperException.DLL, but am now met with the following on trying to compile the project:
The type 'SuperException' is defined in an assembly that is not referenced. You must add a reference to assembly 'SuperException, Version=1.1.0.0 (...)'
The source file referenced by the error doesn't seem relevant; it's the project namespace that gets highlighted in the IDE.
Now, here's the thing:
All uses of SuperException have been eliminated from the project's code.
Compared to another project that compiles fine without a reference to SuperException.DLL, I only reference one more assembly - and that references nothing that my project doesn't reference itself. While it's possible that any of these dependencies could throw SuperExceptions, I'm only catching the base Exception class and in any case... the other project builds fine!
I've done Visual Studio's "Clean Solution" and cleared everything out by hand, many times.
It's not the end of the world to include this reference, I just don't see why it's necessary any more. Nrrrgg. Any pointers welcome!
It's likely a transitive reference, where some type method call returns an instance of SuperException boxed ("downcast") as e.g. Exception, but from inspecting the code in the transitively included code, i.e. code from your external method calls, the compiler knows that you need to be able to have information about that type at some point.
Resharper would tell you where it's the case that you need to add a reference, and you could use Lütz Roeder's aka RedGate's Reflector to scan compiled IL for a reference to this type in two ways: 1) use the search-facility, 2) open each public type you're using and for that one which requires the "ghost" assembly, it will ask you to specify its location.
This most often happends to me when I reference Castle.Windsor but not Castle.MicroKernel. :p
Exit Visual Studio
Delete the bin and obj Folders in your solution directory
Restart and see what happens
I agree with the other comments here.. There is a reference, in plain text somewhere !
I have had similar problems in the past where searching through the project files returned nothing, turns out it was in some other file that wasn't automatically picked up in the search.
I don't think that creating a new project is the solution here.. You need to be positive that NONE of the references in your dependency tree use SuperException.. NONE
I have never experienced this to the point where I have needed to literally wipe the project, I have always found the reference somewhere. Ensure you are searching every file.
EDIT:
Just a point to add, if the location pointed to by the error seems random, that can often mean there is a mismatch between the compiled source and the source code file.. Is this a ASP.NET application? I have had it before where the compiled DLL's haven't been replaced on a rebuild in the ASP.NET temp folder causing things to get.. Interesting when debugging :)
I don't think this is a code issue. What I can see happening is that one of your existing references probably rely on that type in their own types which you are probably creating in your application.
If that is the case you do need that reference even if you don't explicitly use the type and even though the other referenced assembly has its own reference. You sometimes get that issue with 3rd party components which need references to types that you haven't referenced. The compiler is obviously seeing something in one of your existing referenced assemblies and is expecting you to referenced the dependent one.
Since it's a compiler error, there must be a reference or use of SuperException somewhere in the project.
Do a find/replace in the entire project or solution for that type and remove every reference (it's possible you already did this).
If you reference any types that inherits from SuperException (even if the type defined in another assembly), you need a reference to the assembly that SuperException is defined in.
Take the line that the compiler is showing the error on and start tracing the inheritance tree of the objects used on that line, you might find the source of it that way.
Thanks for your answers so far. I've tried every suggestion (except one) to no avail.
The suggestion I haven't tried is to create a new project and add all my stuff to it, the thought of which really tests my will to live. ;) I may try this tomorrow if I can be bothered. Thanks again.
There is really nothing very mysterious about VS projects nowadays - it's all text files, etc. SOMETHING must reference that class/dll, and that something must be part of your project.
Have you really grep'd or findstr'd the whole solution tree, every single file, for a reference to that exception?
This sounds pretty strange. Here's what I would check next:
Check that there's nothing lingering in your Properties/AssemblyInfo.cs file.
Check that there's nothing lingering in your SuperUI.csproj file.
Delete all references and re-add them.
Try creating a new project, and adding all your classes to it.
grep your project folder. It could be a hidden reference in your project, or a project that your project references. Cleanse with Notepad if needed.
If you reference any types that inherits from SuperException (even if the type defined in another assembly), you need a reference to the assembly that SuperException is defined in.
Seconded on that.
You might not be referencing SuperException, but you might be referencing SpecializedSuperException, which is derived from, or somehow otherwise uses SuperException - your grep of the project for SuperException won't be catching it though.
Try have a hack with the trial of NDepend
This is where tools like Resharper really pay off -- a simple Find Usages usually tells me of such "ghost dependencies" several times.
Maybe you could go to your definition of the SuperException class and try to Find All References(). You might also want to investigate if the assembly SuperException is has a circular dependency on your main assembly (e.g., main assembly depends on exception assembly depends on main assembly...).
I’ve had a very similar assembly reference issue that was happening when my C# library had a dependent C++/CLI assembly.
The problem that was I was inheriting a public class from that C++/CLI assembly in my C# assembly library. That meant that the inheritance chain was spanning across multiple assemblies.
I was hoping that any client would be smart enough to indirectly load the C++/CLI assembly any time the C# library needed it, but that was not the case even at compile time.
I got rid of this problem by breaking the inheritance between the classes that were spanning across those two assembly libraries and using aggregation instead.
My client was finally happy and did not require the C++/CLI assembly as a dependency anymore.
In your word you would probably have to make sure that SuitableStandardException does not inherit from SuperException in order to eliminate the SuperException.DLL as a reference.
Use encapsulation instead of inheritance and create a SuperException data member in your new SuitableStandardException.
If that does not solve it, you might have more classes spanning inheritance across some assemblies, in your case SuperAssembly.DLL and superException.dll.
If you can't find all of them try this trick:
Make all your public members and classes in SuperAssembly.DLL internal.
In the SuperAssembly.DLL make friends with SuperException.DLL:
[assembly:InternalsVisibleTo("SuperException, PublicKey=0024000004800000....)]
Make sure that they build and remove the SuperAssembly.DLL reference from any client that already references SuperException.DLL.
grep -R SuperException * in the base of your project (get grep from somewhere first) just to be sure.