i have to fight against a strange issue in my company. we have 2 .net 2.0 (old, i know) apps, which start with an .asmx-file. the code-behind calls a c#-file, which includes a include abcd directive, whereby abcd originates from a 3rd-party company.
one app is in test and it works fine. the identical one is in production and fails with the error Could not load file or assembly 'abcd.dll' or one of its dependencies. The specified module could not be found.
when i look in the related web.config-files, none of them includes a pointer to abcd.dll, which i first do not understand in the context of the productive environment, where everything works. secondly when i look inside the \bin-folder, i see the related assembly/dll. again: this is identical in both systems.
the only difference of both systems is the fact that visual studio 2.0 (does this really exist?) is available on the test system.
please note: i am aware that assemblies have to be added via solution explorer in visual studio too. but i cannot do this as such an installation is not allowed here. but again: in web.config on the test server no reference can be found in the related web.config and everythings works fine.
so my question is: how to get this thing working in productive env?
thanks in advance
You may want to run Dependency Walker (depends.exe) http://www.dependencywalker.com/ and point it at to detect if any dependencies are missing.
I'd also look in the GAC (C:\Windows\assembly) to see if there are any related differences there.
Also, compare IIS setting on the two machines.
Related
I'm trying to download and run working branch onto a second machine from Azure DevOps (formerly VisualStudio.com).
Main machine (VS2017 Pro):
SolutionABC builds and runs perfectly
Branched to SolutionABC-Branch with small changes (external to this issue)
SolutionABC-Branch builds and runs perfectly
SolutionABC-Branch checked in
Second machine (VS2019 Pro):
SolutionABC downloads, builds and runs perfectly
SolutionABC-Branch downloads, but won't build:
Tracing the errors back through the Errors dialog, I get this:
Warning BC40056
Namespace or type specified in the Imports
'Microsoft.IdentityModel.Clients.ActiveDirectory' doesn't contain any
public member or cannot be found. Make sure the namespace or the type
is defined and contains at least one public member. Make sure the
imported element name doesn't use any aliases.
A quick Google search leads me here, so following the instructions there are indeed some issues:
Firstly, how can I solve this please?
Secondly, how does this happen when the parent solution from which this is branched runs perfectly on this machine?
Update
It appears that many of the project references (both to other projects in the solution, and also to Microsoft DLL's) are also missing. Through desperation I xcopied the Microsoft DLL's from the initial project to the branched project. This has fixed the issue, but my questions are still unanswered...
Solution
The problem turned out to be the file/path length limitation of VSTS/TFS. Relocating my local repo to a shorter directory name (e.g. C:\TFS) fixed the issue.
Missing DLL files in \bin folder after downloading fully-working solution to a second machine
AFAIK, this issue should not related to TFS/Azure Devops, it is more related to the small changes or the environment settings. Although you think it is (outside the current issue), it may cause the this issue to arise where you can't see/think it.
To resolved this issue, we need to troubleshooting it:
Since the parent solution from which this is branched runs perfectly on the Second machine (VS2019 Pro), we could create a new branch without that small changes, then check if still have this issue?
Then, add those changes and check if you have this issue again.
Note: Try to remove the references from the SolutionABC-Branch solution on the second machine and add them back to check if this issue has been resolved.
Hope this helps.
How to solve this:
Use the nuget package for the Microsoft.IdentityModel.Clients.ActiveDirectory
What is causing this:
I would bet that this is pointing out a discrepancy between those two machines. Look in the directory on box 1 listed in the properties of the reference and check that the assembly is there. Verify it is in the same path on box 2. Also check the GAC on both machines. VS/MSBuild tries to be as smart as possible when looking for those assemblies and if the hint path says one thing, and it isn't found there, but the assembly is registered, the build will go through fine.
We are for some time now trying to find a solution for server prerendering of SPA, specifically Angular4, for the purpose of SEO.
We have come to try and use aspnetcore-angular2-universal, which seems to be the perfect solution, however, we encounter problems deploying the published build to a local IIS server.
We have posted an issue regarding the problem on the issues page at which can be found here:
https://github.com/MarkPieszak/aspnetcore-angular2-universal/issues/491
We have followed the instruction under "Getting started" & "Deploy" (which can be found here: https://github.com/MarkPieszak/aspnetcore-angular2-universal) exactly but the error still exist.
The support is unresponsive on issues and thus we are posting also here.
The problem is (as mention in the issue linked here) that we get the following error:
Which indicates a problem with the web.config file. However the webconfig file is exactly as supplied in the starter project and seems also legit.
I should mention that building and running the project using npm build:prod and dotnet run works and we can lunch an in memory application from Visual Studio Code, however when taking the published folder to an IIS folder the error occurs.
Any help will be appreciated.
Did you installed .NET Core Windows Server Hosting bundle?
Check if AspNetCoreModule listed in IIS => Modules. Sometimes it not installed properly during #1, even if there was "Succeeded" at all steps. In that case I just removing it via Program & Features, and reinstalling it then.
Once I saw that error when manually copied web.config from sources over the publish folder. Problem is that original web.config contains placeholders like %LAUNCHER_PATH% and %LAUNCHER_ARGS%, which turns to appropriate values (dotnet and .\YourApp.dll for instance) during dotnet publish
Aperantly there were incompebilities between angular5 & universal in serverside.
The https://github.com/MarkPieszak/aspnetcore-angular2-universal seed was downgraded to using angular4.3 instead of 5. When we updated seed, the problem was solved.
I am trying to convert a Windows Forms application to UWP using the Desktop Bridge. Since I have (most of) the source code, I'm attempting the conversion using Visual Studio, as opposed to the command-line tool. My application uses some third-party DLLs whose source code I don't have.
After adding a new JavaScript UWP project to my solution, I'm placing the original application's DLLs in a project subfolder as explained in the documentation.
Some of these DLLs are causing strange errors when I build the UWP project. The errors seem to be caused by duplicate resource entries in the DLLs, but curiously enough, these DLLs are referenced without issue in my standard Windows Forms project.
The errors state:
Duplicate entry
'DevExpress.Data.PropertyNamesRes/DevExpress/XtraPrinting/XpsDocumentOptions'
or one of its parents is defined as both resource and scope, which is
not allowed
I've been digging and searching about these errors for hours but I haven't found any meaningful information. I also used ILDASM to analyze the DLL headers but found no obvious issues in them. Has anyone here faced similar issues? Thanks in advance for any information.
Without seeing the complete error is difficult to say, but I've seen similar errors processing resources. If this is the case, this could be the same as this issue
And can be solved adding this property to the jsproj:
<AppxGeneratePrisForPortableLibrariesEnabled>false</AppxGeneratePrisForPortableLibrariesEnabled>
I am trying to deploy a sparql endpoint using dotNetRDF to www.myapp.com/sparql.
rdfWebDeploy -test worked without errors but then running -deploy shows that there are missing assemblies in these tool.
First is complained about missing NewtonSoft.Json.Net35.dll, so I went into my nuget package and grabbed the dll in the net35 folder. However, this dll is named NewtsonSoft.Json.dll despite the 35 build...so I just renamed it has Net35 in the name and dropped it into rdfWebDeploy.
This worked so far, then it complained about MySql.Data.dll. I downloaded the MySql Connector which had the dll and dropped it into the rdfWebDeploy folder as well.
Finally rdfWebDeploy succeeded, however running the site produced
Could not load file or assembly 'Newtonsoft.Json.Net35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
How can I get this tool to deploy to my Net 4.5 MVC site and get past this Newtonsoft issue? Also, how will I know my endpoint ("/sparql") is working, will it display something if I go there?
This tool hasn't been updated in a while and sounds like it has fallen behind the main code base somewhat, we haven't used the old .Net 3.5 builds of Json.Net in a long time nor do we have any dependencies on MySql.Data anymore. So this sounds like a bug which we'll look to fix in our latest release - this has been logged as TOOLS-424
In terms of what you will see when this is working it will depend on the configuration you have provided for your endpoint(s), a fairly default configuration would give you a query form such as the one seen on our live demo at http://www.dotnetrdf.org/demos/leviathan/ - you can see the corresponding configuration for our demos at http://www.dotnetrdf.org/demos/sampleConfig
Update
The mentioned bug has now been fixed and an up to date and working version of this tool will be available in the next dotNetRDF release currently scheduled for the end of July 2014.
I am working with a .NET 3.5 class library that was created in Visual Studio 2008, and later updated and recompiled in Visual Studio 2010. The strangest thing is happening: One of the Web References that is listed in the Solution Explorer does not actually compile into the DLL (proven by inspecting the DLL with .NET Reflector), and there are no errors or warnings respectively. I tried Googling and searching this site and I could not find any applicable information. Any advice about why this is occurring will be greatly appreciated! Hopefully the information provided is enough; otherwise I should be able to provide more.
Edit: The namespace for the Web Reference shows up in the Solution Explorer, but not in the Object Browser. Some of my colleagues are saying that this is an issue with the Web service itself. I should mention that it is an SAP Web service and during development we are interfacing with a test environment that was recently upgraded and could be acting problematically. I will confirm whether this is the cause once I am more certain, so please don't hesitate to share any relevant information meanwhile.
Edit (2): See my first response to Cyborgx37's answer for further clarification including the client-side error that is generated.
This is slightly baffling: All I did to get the Web Reference into the Object Browser - and hence into the actual DLL at compile time - was rename it to something else, and then revert it back to its old name (which was optional to keep the name the same). Gotta love strange Microsoft issues. Hopefully this helps someone else who ends up running into the same issue!
If I understand correctly, you are wondering why the referenced assembly is not compiled into your DLL.
Referenced assemblies are typically not compiled into the DLL. Your DLL will instead contain a pointer to the external resource and .NET will attempt one of several strategies for locating it (and then loading it into memory so your application can use it).
You may find this article enlightening:
How the Runtime Locates Assemblies
To successfully deploy your .NET Framework application, you must understand how the common language runtime locates and binds to the assemblies that make up your application. ...