I have a problem running my 1-click application. It stopped working with an error code "Application validation did not succeed". The problem is related to Mono.Cecil.dll and related signature validation.
If I turn publish status of Mono.Cecil.dll to exclude in VisualStudio/Properties/Publish/Application files the app starts working ok for majority of users, but some users report errors with certain functionalities.
Any idea what could be the issue? I took over some legacy code so I am not sure why this dll was included in the code. Previusly it was working ok with this dll and I did not modify it.
Errors:
System.Deployment.Application.InvalidDeploymentException
(SignatureValidation) Strong name signature not valid for this
assembly Mono.Cecil.dll
Copied from the comment.
You have to be very careful about what libraries/packages are being referenced by your project, as they can bring harms to your end users if coming from certain sources.
Mono.Cecil, as a famous open source library, has been known to have tons of sources and only its NuGet package or its source code repo on GitHub can be trusted as they are managed by the original author.
The issue disappeared once you resolved that mysterious reference, but you can check out other references to make sure similar things won't happen in the future.
MSBuild bin log can reveal almost everything about the build, so you might start from there.
Related
We've been battling with a strange issue for a couple of days now. Have searched the net for answers but none seem to solve the error.
Our scenario is: our organization has a Silverlight 5 application, which was developed in VS 2010, and everything was working fine. It is actually running in our production servers.Recently we migrated our development machines to VS 2015, and the machines themselves (new ones for the dept). The OS is Windows 7, same as before.
At first we were welcomed with that nasty MatchTimeoutInMilliseconds error, due to the MS Framework. Eventually MS released the 4.6.2 Preview version which covered this issue.
Ok. So back to implementing the changes requested, we created a new method in our webservice, and it complied just fine. We do have the [OperationContract] and [DataContract] tags in place. There is a question posted and answered with the justification that these tags were missing.However, when we go to the SL app and update the WS reference, we get this "Custom tool error: Failed to generate code for the service reference ..."
Custom Tool Warning messages include
"Cannot import wsdl:binding..."
"Cannot import wsdl:port..."
"Cannot import wsdl:portType..."
"No endpoints compatible with Silverlight 5 were found. The generated client class will not be usable unless endpoint information is provided via the constructor."
We're puzzled, because then we thought we might have done something wrong, so we rolled back the changes, and updated the service reference with no changes, and we get the same error. The Referece.cs file is generated with no code, and all references to the webservice are no longer recognized by the compiler.
We've also read some posts that offer as a solution unchecking "Reuse types in referenced assemblies". Doing that does clear these errors, only to generate others, since our app was built on this premise.
We've also tried deleting the service reference and adding it back again, but to no avail.
Eventually we reverted the SL app to the point it was compiling, which was before updating the webservice reference, republished the WS with the new method, and manually added the new method to the Reference.cs file, tested it and it works.
This, however, should not be -the- solution. It's a hassle and prone to errors.
We'd appreciate any help in solving this matter, or an insight as to why this is happening.
thanks
The whole problem is that, for some reason I still haven't found, VS fails to generate the code for Reference.cs.
As a workaround, we've managed to generate the Reference.cs file by using the SlSvcUtil.exe tool, located (on my machine) at "c:\Program Files (x86)\Microsoft SDKs\Silverlight\v5.0\Tools".
In order to get the same code as the one generated before the migration, I've used the following command and options:
SlSvcUtil.exe my_ws_address /namespace:"*,my_class_namespace" /ct:System.Collections.ObjectModel.ObservableCollection`1 /r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\System.Windows.dll" /edb /ser:Auto
I didn't use the /out switch, but rather ran the command on my desired output directory. But you might want to look into that switch before running the command.
For a project I am working on, I need to solve a mathematical model. I chose to do this using Microsoft.Solver.Foundation and the SolverFoundation.Plugin.LpSolve plugin. Both associated .dll files for these extension seem to work fine, as VS2015 recognizes and references them without a problem and compiles and runs my program without errors.
This is however up untill I try to actually solve my optimization, which needs "lpsolve55.dll" to work. I have downloaded this dll and put it in my project's bin/Debug folder, but for some kind of reason VS2015 just doesn't recognize it. I.e.
I can't reference it by simply browsing to it from my "Add Reference" tab.
It's impossible to (un-)register it via the regsvr32 cmd-prompt application, as it doesn't have any DLL (Un-)registry entry points.
The TlbImp.exe cmd-prompt application can't handle it.
So basically, after discovering the above (after trying the most-common internet solutions), I still feel quite dissatisfied to get the error message while I try to solve the optimization -
Unable to load DLL 'lpsolve55.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
The wierd part is also that I have another project in which I solve a similar problem, where there are absolutely no problems at all using lpsolve55.dll....
Some quick facts:
I reference .NET framwork 4.5.2. I have changed it to 4.5 as well as 4.0, but this didn't change anyting.
For as far as I can tell, the bin/debug folder of my projects are identical.
I am working on a fully updated windows 10 OS, 64 bits, while using visual studio 2015.
My question would thus be whether or not some of you have encountered a similar problem and if you were able to solve it in some way.
Highly appreciated!
After some careful analysis, I have found the answer to the problem. To be honest, as most things are, it was quite simple in the end. The lpsolve55.dll wasn't recognized because I didn't have my new bin-folder in the Path, which I did have with my old project. I simply forgot.
On a further note however, after the lpsolve55.dll directory was added to the path, I still got an error telling me there was no model to be found that could solve my directive. Since the error occured when I was calling the LPSolverDirective(), some research landed me on the following page:
http://lpsolve.sourceforge.net/5.5/MSF.htm
Above page gives a complete and stable way of how to acces lpsolve55.dll using the LPSolverPlugin straight out of Microsoft.Solver.Foundation.dll. After following the method in the link that involves editing my projects' bin/Debug and bin/Release folders, I got the LP model up and running within no-time.
Morale of the story - read the documentation. I am a bit of a beginner in programming entire multi-project solutions and using customly-added dlls, but hopefully this helps someone else experiencing the same. In the end, I learned a lot by simply trying different methods of getting it to work, so no time was wasted.
I have had the pleasure of using ISLE and its now got to the point where I have to post a question on SO. Ohh the headache.
I have tried added the Extended WPF Tookit via nuget and manually to my application but with no luck getting ISLE to include these assemblies when it builds the installer. I have done a dependency scan in ISLE and in both scenario the dependencies are present.
I am using a TeamCity (v8.1.1) build server to automate the build. Everything works fine except that it will not include the above mentioned assemblies in the package.
How do I solve this problem?
Update #1
With some more research it seems that ISLE on the dev. box picked up a wrong version of log4net.dll while the build server found the correct version.
Resolution - Cleared all log4net.dll found in the "%temp%\Temporary asp.net files" folder.
You solve the problem by turning off dependency scanning and take responsibility for knowing what your applications needs to run and what the best way for deploying it. Dynamic installation authoring has never fully worked and it never will. When you take into consideration all the different kinds of apps and the way they take their dependencies it becomes obvious.
The easy button is an illusion.
I am unaware of why ISLE has these inconsistency and obvious logic problems however I have resolved my issue, albeit the solution is shaky.
Issue #1
Firstly I encountered a XamlParseException due to a TypedInitializationException. An assembly could not be loaded and that assembly was noted in the Exception which turned out to be log4net. The log4net assembly was in the folder however it was the wrong version.
Somehow ISLE found an older version of this assembly in the "%temp%\ASP.NET Temporary files" folder and used that in the package. Clear all these files and give ISLE no choice but to use the assembly you have provided. NOTE: Don't get gungho and delete the culprit assembly if found in the folder of one or more of your installed applications - it just might stop working.
Issue #2
I realized that not only were the Extended WPF Toolkit but the output of a dependent console application was missing from the install directory.
You would expect ISLE to find all dependencies however it doesn't.
Based on the advice provided by ##Christopher Painter I added the primary output of the console application dependency manually. I expected this to solve the console dependency issue however it turned out to solve both.
Now does ISLE break internally if the one of the dependencies is unavailable, locked, or some exception occurred while adding to the output causing it to stop at that point and not add any more dependencies. Who knows, but I am sure there are some flaws within ISLE Microsoft if you are going to ship a 3rd party and only a 3rd party installer ensure that it works properly first.
Update #1
Running the build a second time on the TeamCity server resulted in the Extended WPF Toolkit not being added again. So it seems again the ISLE installer is really shaky.
Issue #3
Another option to solve the missing Extended WPF Toolkit assemblies would have been to add then explicitly as dependencies. ISLE however adds a explicit rather than relative path location to these files meaning that you need to recreate the folder structure on your build server (not good).
If anyone has a better solution I would love to hear it. This request also goes out to Flexera Software and hopefully the answer is not to upgrade to the PRO version or pay for support.
I'm trying to set a breakpoint in the source code for MVC 4.
Here are the steps I took:
Cloned the Git repo at git clone https://git01.codeplex.com/aspnetwebstack.git
Compiled in visual studio
executed: sn -Vr *
Added an MVC 4 project to the solution
Removed the reference to System.Web.Mvc and added it back from the local project in the solution
Still, when I run it I get the error about the assembly signing. I admit I have never had to do much with assembly signing - but from what I understand the sn command disabled that.
Any suggestion on how I can go about successfully setting it up so I can step through the code?
Error I'm getting:
Could not load file or assembly 'System.Web.Mvc' or one of its
dependencies. Strong name signature could not be verified. The
assembly may have been tampered with, or it was delay signed but not
fully signed with the correct private key. (Exception from HRESULT:
0x80131045)
Is the the "one of its dependencies" part that is screwing me up maybe? Am I making a wrong assumption maybe that I can just reference one of the locally built assemblies? (I'm just guessing)
The build instructions mention downloading and running (from an elevated command prompt) SkipStrongNames -e, the executable being available here.
However, I think it's more useful to be able to debug the framework and third-party libraries right in your project, without having to mess with the source of those libraries. You just need the debug symbols and to configure VS accordingly. Regarding symbol servers, if you can, I'd start using symbolsource.org for better coverage.
So I recently updated my software and with the new version I supply a new dll-file, lets call it My.dll. Now, the old version works just fine on every computer I have tried.
The problems began with the new version. Specifically, so far on at least one computer, it states that "Could not load file or assembly My.dll". This even happens when I have dropped a copy of the software on a network drive and run the software directly from there. It works on every other computer but one, which still gives the exact same error where other computers work fine.
The dll in question is even in the same directory as the executable, so I'm really quite bummed here. I tried to google around a bit as well, but all the issues I found were related to ASP.NET specifically. Any ideas on how to go about finding the problem would be much appreciated.
It is possible that the computer in question has a DLL added to it's Global assembly cache. This would take priority over the DLL in the same folder.
More information about the GAC: http://msdn.microsoft.com/en-us/library/yf1d93sz(v=VS.100).aspx
Is there an old copy of the DLL lying around? Perhaps with a different name? I had a similar issue when I changed the name of a dll. Internally, the namespaces were the same.
In my case, an older version of the DLL was still there. .NET got confused with two assemblies in the bin directory having the exact same namespaces and classes, couldn't decide on which to load, and threw an exception.
Removing the older version of the dll solved the issue.
Use the Assembly binding log viewer and set it to log failures. This will give you some clues as to why it is not loading.
You could take a look at the error log using the Assembly Binding Log Viewer. First you have to turn on logging.
--Right Click on Project
--Goto Properties->Build tab
--Change Platform and Platform Target to Any CPU, Save and run