after one hour googling, I can't find the right answer to the issue I'm experiencing, hope you can help me.
I have a C# framework 3.5 class library project, so I signed it creating a simple key (NOT delayed signin) and then I obsfuscated the DLL.
Then I'm trying to access that assembly from a Windows form application, but when I make some call to any method of the assembly I get the error: "Strong Name Validation Failed".
I don't know if I should sign the Windows application too to refer to the strongly named assembly, or add some sort of special tag at the using directives in the source code of the Windows application.
I'm new working with strong names, so please give me some advice in how to deal with this. I need to strongly name the assembly in order to guarantee that no intruder could replace my version of the assembly.
Thanks in advance.
sorry for taking away your time, I found the reason for my issue and the solution for it:
First of all, when I obsfuscated the assembly, the generated SNK didn't worked anymore, so the solution is to re-generate the SNK after obsfuscating the assembly.
Second, I needed to include the SNK file on my Windows Application in order to validate the strongly named assembly.
With both changes, everything worked fine for me.
Thanks anyway for your time.
Related
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'm building a shell extension using Sharpshell and LibTiff/Tiff2Pdf. It's a simple dropdown menu in Windows for converting files. In order for the solution to build all assemblies must require a strong name, include the project itself.
Anyone know how to rebuild LibTiff.Net in Windows with a strong name? If it was my own assembly it would be as easy as adding a new key. However, I'm lost on this one. Any help would be greatly appreciated.
You'll need to re-build the code and then sign it - that's the only way. Maybe the best thing to do would be to directly request that LibTiff.Net provide a signed version of their assembly.
Otherwise, you could disassembly the code (see ildasm at https://login.live.com/login.srf?wa=wsignin1.0&rpsnv=11&checkda=1&ct=1376595663&rver=6.0.5276.0&wp=MCLBI&wlcxt=msdn%24msdn%24msdn&wreply=http%3a%2f%2fmsdn.microsoft.com%2fen-us%2flibrary%2ff7dy01k1.aspx&lc=1033&id=254354&mkt=en-US) but remember that depending on their license, you may be legally forbidden from redistributing it after rebuilding it.
Ok this question is more about understanding what the issues are as I dont think anyone will be able to tell me how to fix the problem.
I am writing a .net 4 application and I have a 3rd party dll ( hasp dongle protection ) that I want to reference.
Visual studio allows me to create the reference fine and use classes contained within the dll within my code.
The first issue occurs when the program is run and the dll is actually loaded. I then get the following error.
System.BadImageFormatException: Could not load file or assembly
'hasp_net_windows.dll' or one of its dependencies. is not a valid
Win32 application
This weblink states how to fix this error. Coud someone expalain what the issue is and why im getting it.
After following this advice I then set the main project build to x86 and I then get another error replacing the other. The new error is:
System.IO.FileLoadException: Mixed mode assembly is built against
version 'v1.1.4322' of the runtime and cannot be loaded in the 4.0
runtime without additional configuration information
This weblink states how to fix the error, but I dont have an app.config in my project and want to avoid having one if at all possible. If someone could explain what the issue is again that would be helpful?
Please let me know if you require anymore information.
The issue is the "bitness" of your application. Once chosen (32 bit or 64 bit) all DLLs within that process need to be the same. This exception tells me that one of your DLLs is the wrong "bitness".
You simply cannot have DLLs with different compilation targets within a given process, a process has "bitness" affinity.
If this is a third party unmanaged DLL then it is very likely 32-bit compiled.
Setting the build output as x86 for the root project (the one that creates the exe) should suffice as this will dictate the process that is created. Any other .NET projects can then simply be Any CPU and will fit in either the 32 or 64 bit runtimes.
Unfortunately for your second issue, the provided link is the way to solve it. There is nothing wrong with having an app.config in a project and you haven't stated why you don't want one.
The answer by Adam Houldsworth notwithstanding, I'd like to add that it is possible to do it without an app.config. However, this requires a tiny bit more work and potentially a proper understanding of COM interop. Whether it's worth the trouble is up to you of course ;).
You can set useLegacyV2RuntimeActivationPolicy programmatically by using the ICLRRuntimeInfo::BindAsLegacyV2Runtime method.
A quick rundown on how to do this is posted in this blogpost. Take note of his warning though, which might make you think twice in using this approach:
This approach works, but I would be very hesitant to use it in public
facing production code, especially for anything other than
initializing your own application. While this should work in a
library, using it has a very nasty side effect: you change the runtime
policy of the executing application in a way that is very hidden and
non-obvious.
I cannot use an app.config file because the assembly is loaded via COM from a native program.
I found the library that supports .net framework 4.0. here. In this scenario, no other solutions had worked for me.
I would like to keep version in my .net applications and let the .net to manage it. I don't really understand how it works. Is the version number per project ? How .net manages versions? If anyone could please explain it briefly i will be grateful.
What I usually do is to keep a SolutionInfo.cs that contains all the attributes that are common for the projects of my solution, for example the version-number. I keep this file in the solution root.
I then link that file into the project (right click the project and Add->Exsiting item... -> Add as link (the little arrow on the add button)).
I then can increment the version number in a single place and it will be updated in all the projects that links that file.
For more information on that for example see: http://jebsoft.blogspot.com/2006/04/consistent-version-numbers-across-all.html
The version number is per-project (.csproj file), so per built .dll or .exe file. The version number is embedded in the .dll or .exe, and can be viewed using (for example) Windows Explorer by right-clicking on the file and selecting Properties.
MSDN contains an explanatory article about how to use AssemblyVersion and AssemblyFileVersion at http://support.microsoft.com/kb/556041
[AssemblyVersion] is a very big deal in .NET. Every type in your program is imprinted with the assembly version, it is part of the type identity. In other words, when the version of your type changes then you should also change the assembly version. This forces all other assemblies that use your type to be recompiled.
One thing you can do is to let the build system automatically increment the version. You can't call this 'managing the version' by any stretch of imagination. Because now just rebuilding your assembly, even without making any change in the source code, will make your assembly incompatible with other code that uses the types in that assembly.
Clearly this can only work well if you recompile all the code in your solution.
Well, that's not great unless you like sword fighting. Furthermore, sometimes you want to make a simple bug-fix in your code. The result is an assembly that's still 100% compatible with the original version. And you don't need nor want to recompile everything else that uses it. You just want to send that one assembly to your customer. Clearly that can only work well if you don't let the version increment automatically.
So what you really need is some kind of tool that can magically determine that your source code, the publicly visible part of it, is no longer compatible with a previous version. Or the changes you made to the non-visible part of it are changing the behavior of the code too much to disallow other code that use your types to continue to use it without some changes in their code.
There's only one tool that I know of that can do this, the one we have between our ears.
I am writing a WPF client that consumes services from an ASP web service (VS2010, .net 4.0). It was working just fine until yesterday when I suddenly get the above compiler error. Double-clicking on the error takes me to Reference.cs and highlights just about anything along the lines of:
[System.Runtime.Serialization.DataMemberAttribute(EmitDefaultValue=false, Order=2)]
(The 'Runtime' object is highlighted as not being in the MyAppNameSpace).
I've tried googling this and re-adding the service reference and re-adding the assemby reference but nothing works and I'm completely stuck. Reference.cs is automatically generated and I'm still relatively new to VS2010 so I'm not sure where to go with this.
Hoping someone here can point me in the right direction...?
I had the same problem. After hours of trying to solve it I realised I had a class in my library called system. What a cock.
Your problem is that you had defined a "System" namespace somewhere that the compiler and Intellisense were finding before the real "System". The solution is to remove the offending namespace, then clean and rebuild the project.
I had the same issue with a VB project only I had no old code as it was a new service reference. I did not have any other namespace with System in the name. The solution for me was to make the following series of replacements:
VB
in Reference.vb
Replace System. with nothing
Then replace "Runtime.Serialization" with "System.Runtime.Serialization"
Lastly replace <Global.ComponentModel with <ComponentModel
C#
in Reference.cs (I didn't try this but expect it will work)
Replace System. with nothing
Then replace "Runtime.Serialization" with "System.Runtime.Serialization"
Lastly replace [Global.ComponentModel with [ComponentModel
One other detail that might lead someone to a root cause is that the service wsdl was coming from an old style asp.net web service (.asmx), here: https://api.mindbodyonline.com/0_5/ClassService.asmx?wsdl
Update
I've subsequently found that changing the target framework to 4.5.1 resolved my compilation issue. Also I had the root cause was that I had different framework versions targeted by my web project and the class library containing my service references. Once I changed them all to 4.5.1 everything was happy no changes to Reference.vb was needed.
Well, for the sake of anyone looking for an answer in future - I gave up trying to fix it and copied a backup of the project files over the existing ones and brought the changes since them in manually. That fixed the corrupt referencing issue.
I had a similar problem, but with a different solution.
My project used to be called "JobRunner", but it changed to "NGB.JobRunner". In the project settings however the default namespace and assembly name was still "JobRunner", and the Reference.cs file was being generated with this namespace.
I have no idea why it was causing problems, but when I fixed the default project namespace and assembly name, and re-added the service reference, problem solved!
I had the similar problem. It was the upper case 'T' in time which was causing the issue. I was doing RunTime but the correct was 'Runtime'.
What a time waste due to a typo!!