I'm busy writing a custom Windows Services to handle MSMQ messages on a server, but the installation (using InstallUtil) keeps failing with the following error:
"System.InvalidOperationException: Unable to get installer types in
the 'x'.exe assembly. The inner exception
System.Reflection.ReflectionTypeLoadException was thrown with the
following error message: Unable to load one or more of the requested
types. Retrieve the LoaderExceptions property for more information."
I am using 3 of my own assemblies in the service. All of them are set to 'Copy Local' and all other referenced assemblies are in the GAC. I have verified that all other referenced assemblies not in the GAC are in the the folder containing my services' .exe file.
I have also tried signing my assemblies (if that is worth anything...)
I have also looked around on Google, but in most cases the problem was either solved via a service pack, or installation of some proprietary software, which obviously solved the missing dependency issue.
I wrote a simple POC service, without referencing any 'outside' assemblies which worked fine...
I'm developing and testing on a Windows 7 machine.
Any ideas?
Thanks!
EDIT:
Ok weird... I was using PostSharp for exception handling and logging... I removed the references to PostSharp and my aspects, and it installed with no problem... o_O
Is there any reason why something like PostSharp will not play well with Windows Services?
Without the installer, have you tried registering your service with all dependent assemblies? were you successfully able to register?
If this has worked, then -
Is your service registration action is post install complete action in your installation authoring steps?
Sorry fo my english. I worked 2 days on this problem and i found that installutil works only if installutil and service and dependencies files in one directory.
installutil service -> works fine
installutil ServicePath\service -> dont work if dependencies in ServicePath directory.
Ok, I found the problem... I applied the same PostSharp aspect twice to a method. So I had Method1 and Method2, both have the [MyException] aspect applied. Method1 calls Method2 so the aspect is 'applied' twice, which didn't go down well with the Service Installer. I removed the aspect from Method2 and all worked fine!
Related
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.
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.
Attempting to setup a unit test that calls a WCF service. Running under NET4.6 The client uses the basicHttpsBinding.
Have copied the system.serviceModel config section across (which includs the basicHttpsBinding tags to the unit Test's app.config.
When I run the test (xUnit) I get the following error when the Client constructor runs.
Exception thrown: 'System.Configuration.ConfigurationErrorsException' in System.Configuration.dll
Additional information: Configuration binding extension 'system.serviceModel/bindings/basicHttpsBinding' could not be found.
Verify that this binding extension is properly registered in system.serviceModel/extensions/bindingExtensions and that it is spelled correctly.
Another answer suggested adding the following (to ensure at least net4.5 is in executd for the test.
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6"/>
</startup>
Any clues?
Edit: This is only failing under resharper 10 Test Runer. If I use CTRL-R, T and run against the InBuild runner it works fine.
I have tried a few options in Resharper,
force CLR to 4.5,
disable/enable shadow copy, and
run in own
appDomain.
none changed the result.
I don't see any obvious reasons for this to fail - the xunit plugin (now a part of ReSharper itself as of version 2016.1) does work with app.config files. If you could log an issue, and ideally attach the solution (you can do so privately, so only JetBrains staff can see, or we can do NDA if required) I can take a look for you.
I suspect it is similar to why my similar WCF ordered tests fail under the Microsoft tools...Running a single test works because it is run directly out of \bin\Debug...but running multiple units as an ordered test fails because to run it Microsoft uses an executable sandbox called QTAgentXXXXX.exe.
To find out what executable is running your tests, simply break point early on, and dump out the AppDomain.CurrentDomain.SetupInformation (note the TargetFrameworkName and ApplicationName properties specifically) and also dump out a call to System.Diagnostics.Process.GetCurrentProcess().MainModule.FileVersionInfo to get the executable path.
Load this executable into ILSpy and you can check out the framework it was compiled against.
The Microsoft QTAgent apps are under C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\ and there seems to exist several varieties depending on the .Net Framework being used or whatever weird detection scheme they use to pick one....
UNFORTUNATELY, I observe that the most recent QTAgent32_40.exe is compiled under the old 4.0 Framework and before you ask, yes there is a QTAgent32_40.exe.config and no, adding the supportedRuntime setting with sku=4.6 does not encourage it to operate any differently (Maybe you would see different results tweaking your resharper 10 Test Runer config though). And I've tried the assemblyBinding appliesTo attribute trick mentioned in several threads to no avail as well.
I attempted to use ILSpy to recompile my own version of QTAgent against 4.6.2 but a lot of the Microsoft.VisualStudio.blah.blah assemblies being referenced have a lot of internal classes that you cannot build against. These assemblies have this crappy assembly attribute called InternalsVisibleTo which lists what external libraries and executables are allowed access to these internal classes. The QTAgent executables are among these attributes, which is why they can use them from those assemblies. So it would be a very long and deep rabbit hole to see if one could essentially decompile ALL these related assemblies and recompile the unit testing framework. That is a lot of research for such a small gain. I say screw Microsoft's Unit Testing framework. It is fraught with other issues as well. My co-worker keeps suggesting to use NUnit. I think I may give it a try.
I'm writing a program in monomac to ftp files to a server. I used the FtpWebRequest as
FtpWebRequest request =(FtpWebRequest)WebRequest.Create("ftp://serverip/filename");
When I'm running this code in monodevelop its running properly. But when I release this and runs outside monodevelop I get the error "An Exception as thrown by the type initialize for System.Net.WebRequest.
I researched for this error and found it has problem with the library libc.dylib. If I change the DYLD_FALLBACK_LIBRARY_PATH in launch script of the app(AppBundle/MacOs/AppName edit with TextEdit) as
export DYLD_FALLBACK_LIBRARY_PATH="$MONO_FRAMEWORK_PATH/lib:$DYLD_FALLBACK_LIBRARY_PATH:/usr/lib"
(added /usr/lib)
then it is sending the files. But I have to install mono framework in all system to run this app. Once i create a mac installer package i cannot edit the the launch script. I tried copying libc.dylib file from /usr/lib to Appbundle(App/MonoBundle/) but still the error exists.
Can anyone help me?
I had this issue. Are you adding monomac dll's to the app bundle?
It tries to be clever and remove unused methods and classes.
I found that it would often not include methods it thought were not being used by mistake.
I'm not sure how to force it to include the missing methods, however you can solve this by turn off linking in the package settings. Unfortunately this makes the app much bigger.
I've only been able to find a couple of people online mentioning this, and it seems to be as simple for them as adding the service reference.
However, when I attempt to add a service reference for my WCF service (which works correctly in a regular console app, so I have ruled the WCF out as the problem) I receive a host of errors.
Warning 5 Custom tool warning: No endpoints compatible with Silverlight 3 were found. The generated client class will not be usable unless endpoint information is provided via the constructor.
Warning 6 Custom tool warning: Exception has been thrown by the target of an invocation.
Warning 2 Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.DataContractSerializerMessageContractImporter
Error: Could not load type 'System.Runtime.Serialization.DataContractSet' from assembly 'System.Runtime.Serialization, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.
Warning 4 Custom tool warning: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is dependent on.
Warning 3 Custom tool warning: Cannot import wsdl:binding
Detail: There was an error importing a wsdl:portType that the wsdl:binding is dependent on.
Error 7 Custom tool error: Failed to generate code for the service reference 'ServiceReference'. Please check other error and warning messages for details.
I find it strange that the first error mentions Silverlight 3, as I just completely uninstalled and reinstalled all of my development tools to ensure that I was using the latest version of .NET and Silverlight.
These errors look similar to the ones I see if I attempt to create a new Silverlight project and do not check the box "Enable WCF RIA services". I have not been able to find any means to enable that for WP7, if that is indeed the problem.
Any assistance from you scholarly gentlemen (and gentlewomen) would be much appreciated.
I ran into the exact same error, and changed the collection type to System.Collections.Generic.List instead of System.Collections.ObjectModel.ObservableCollections. This was odd since I did not even check the box for "Always generate message contracts".
Hope that helps.
Mmmm, I just changed the service reference config by unticking the "reuse type ...." box and then update worked and it generated the service config file. Not sure if this will help you?
Remember that Silverlight - even for Windows Phone, which uses a specialized version of Silverlight 3 - does NOT work with all WCF Service bindings/endpoints, but instead only supports a subset (which excludes WS-HTTP bindings, for example.) Your simplest bet is to create your WCF service for Silverlight applications using the "Silverlight-enabled WCF Service" template in Visual Studio (under Add/New Item/Silverlight).
This blog entry (http://blogs.msdn.com/b/silverlightws/archive/2009/03/20/what-s-new-with-web-services-in-silverlight-3-beta.aspx) from the Silverlight WCF Team Blog should shed some light on the possibilities. You may want to check out he whole blog (http://blogs.msdn.com/b/silverlightws/), as it has some interesting how-to and gotcha articles.
This problem occurred when you run the Visual Studio with Administrator Privilege. What you can do for a workaround is run the Visual Studio without Administrator Privilege, add the web service reference that will generate the proxy classes and close the solution. Open the project solution again in Visual Studio with Administrator privilege. A bug report already file in Microsoft Connect.
https://connect.microsoft.com/VisualStudio/feedback/details/624984/error-warnings-when-adding-web-reference-on-windows-phone-7-project?wa=wsignin1.0
Yes this is one strange Error. You will be able to return Strings, Integers etc but anything else like ArrayList and so forth you will get this error.
There is nothing wrong with your code, there is just a bug with VS. Microsoft have fixed it (check service packs) but if you are programming for Windows Phone 7, the bug is still there.
You have Delete the Service, Then Bin and Obj Folder. Save and close VS. Then restart the Project, Add the Service Ref (DO NOT DEBUG/RUN the app). Oh Yes DO A BACKUP FIRST. It should be ok. You may have to repeat this process everytime you Update the Service.
This should fix it, if not, you may have to open a new project or if possible recreate the Webservice.
The answer is yes, you can access WCF services from WP7, and like a previous poster noted it only supports WS-HTTP. In the case that you are trying to access a WCF Service for a Silverlight application then there are a few things that you need to do:
Update your Silvleright Toolkit to the latest. Go get it from Codeplex
Add a reference to Microsoft.ServiceModel.DomainServices.Hosting to your silverlight project.
Go to the Web.Config and add the soap endpoint:
<domainServices>
<endpoints>
<add name="Soap"
type="Microsoft.ServiceModel.DomainServices.Hosting.SoapXmlEndpointFactory,
Microsoft.ServiceModel.DomainServices.Hosting"
/>
</endpoints>
</domainServices>
Do not worry about the "system.serviceModel" warning; ignore it
Add the service reference. "But, which uri?" you ask. The address of your service is this one: [namespace of your ria service]-[classname of your ria service].svc where . are replaced with -. So, if I have created my service inside of a Services directory in my SL application and the namespace looks like this:
namespace myApplication.Web.Services
{
[EnableClientAccess()]
public class SuperService ....
then the address would be:
http://localhost[:port]/Services/myApplication-Web-Services-SuperService.svc
Let the tooling do the rest. If you get some funky errors then save and close VS and start again and it all works.
I hope that this is the answer that you are looking for.
The following solved my problem:
I created a new WP7 project added the wcf service.
Then I copied the Service References folder to the directory of my project that gave me this problem and restarted Visual studio and built the application.
You should get namespace errors inside your Reference.cs; just change the namespace to the current project namespace.