I have an MVC5 Web application (VS2012) which has a reference to a WCF Application.
The architecture looks like this:
- Business library
-- References to DAL
- DAL library
- WCF application
-- References to Ressources
-- References to Business
-- References to DAL
- Web application
-- References to WCF application
-- References to Ressources
- AzureCloudService
-- WebRole for Web application
-- WebRole for WCF application
- Ressources
-- References to Business
-- References to DAL
I have created a AzureCloudService with 2 WebRoles for Web and Wcf applications. When I publish the AzureCloudService, no errors are thrown.
But when I go to the Web application on Azure, many references or assemblies are not found. So, I had to add the following line in .csproj file:
<Reference Include="Tools, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL" />
Because the project reference was not enough:
<ProjectReference Include="..\Tools\Tools.csproj">
<Project>{guid}</Project>
<Name>Tools</Name>
</ProjectReference>
But, when I added Wcf application and Ressources references, it asks for Business even if there is no project reference in Web Application. After all, I ended with the following error which makes me feel that I'm doing wrong. Has somebody a hint or advice please?
Couldn't find type for class Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=2.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
Of course, the following line is present in the .csproj but doesn't seem to work ... or I don't understand something.
<Reference Include="Microsoft.WindowsAzure.Diagnostics, Version=2.5.0.0, Culture=neutral, PublicKeyToken=somenumber">
<Private>True</Private>
</Reference>
UPDATE:
After some research, I've found out that all the project references in my WebRoles are not included while the Cloud Services publication.
Firstly, I tried to set Copy Local to true (even if they already were).
Secondly, I deleted my WebRoles and recreated them.
Thirdly, I try to add some dummy code to reference the projects indirectly as suggested in this post: MSBuild doesn't copy references (DLL files) if using project dependencies in solution
Then, I tried to add the project dependencies on the Cloud Service Project.
Then, I tried to create a package, rename .cspkg in .zip, unzip it, add the missing dlls to the unzipped WebRole .cssx, and re deploy as suggested in this post: http://blog.toddysm.com/2010/02/windows-azure-deployment-did-you-forget-to-pack-your-dlls.html
I know there are scripts for post build events, but I don't succeeded to create one.
For now, I have to access the Cloud Services VM via Remote Desktop and copy/paste the .dll from my local "/bin" directory to the approot and siteroot "/bin" directories.
However, when an instance is destroyed and recreated due to Azure scalability, the .dll are gone.
So, I'm desperate with these projects dll which are not sent.
Any ideas please?
Related
is there a way to avoid nuget package references to ease development on a developers machine?
we are currently about to move some of our projects in our "shared" solution to the new csproj file structure (using <Project Sdk="Microsoft.NET.Sdk">) and using <TargetFramework>netstandard2.0</TargetFramework>.
By doing so we had to include <PackageReference Include="System.Text.Encodings.Web" Version="4.7.0" /> and changing some of our code in project "S" of our shared solution.
Within another solution backend we are having multiple projects. Some of them are referencing the assembly of project S by using assembly reference to S.dll like so:
<Reference Include="ournamespace.S">
<HintPath>..\..\artifacts\Shared\ournamespace.S\ournamespace.S.dll</HintPath>
</Reference>
When we build every works fine. However when running our web application W from backend solution we get this exception:
System.IO.FileNotFoundException: Could not load file or assembly 'System.Text.Encodings.Web, Version=4.0.5.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
Before we have migrated our shared projects to the "new SDK" project file format, before using .netstandard2.0 (we were using .net framework 4.7.2) and before we switched the package reference to System.Text.Encodings.Web (we were using <PackageReference Include="AntiXSS" Version="4.3.0" />) we have not received any error.
The only way i can think of is that we would need to switch from assembly reference for S.dll to use nuget - to get S dependencies.
However using nuget packages for our shared solutions projects and developing in backend projects would become a nightmare as we would need to create a new nuget package (and publishing it) on every change of S and would need to increase the version number in the package references in backend projects all the time. Also this would become very impractical as our developers are using various git feature branches too (thinking about versioning conflicts; having to release unfinished packages and maybe using version suffix "alpha_"+{branchName} to distinct the branch that this version is coming from).
How to develop on localhost? Is there a way to avoid nuget (but getting its dependencies resolved correctly!)?
I was already reading about having assembly references for local development while using nuget package references for CI builds by using conditionals in the csproj file (however this is also not working very well with VS2017; also this would not resolve our problem with the dependency problem written above on localhost)
What other possibilities are there? Is there a best way on how to handle this?
Thanks in advance!
P.S. I dont want to include S's dependencies to every project that references S by using package references there as well. This would not be a solution and becomes more cumbersome when S might get new dependencies for whatever reason.
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
solved my problems (see How to get .NET Core projects to copy NuGet references to build output? for details)
I added a project to my web site solution. Everything built fine locally and on the build server.
I added a line in web code to call a method in the new project. Everything built and worked fine locally, but it broke the build on the build server.
I got a pile of errors going something like this:
warning MSB3268: The primary reference "C:...\ProjectName.dll" could not be resolved because it has an indirect dependency on the framework assembly "Assembly.Name (e.g. System.Runtime)", Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.5". To resolve this problem, either remove the reference "C:...\ProjectName.dll" or retarget your application to a framework version which contains "System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
After all the warnings, the build failed with an error indicating the namespace ProjectName could not be found. Makes sense considering the project's dependencies couldn't be resolved.
At first I wondered if there was an issue with targeting the wrong framework. But there was a mix of 4.0 and 4.5 projects referenced by the 4.5 website. This was the first one that had failed.
The only difference between this and the other projects was that it referenced third-party DLLs. So apparently their dependencies are the ones that couldn't be resolved.
This post held the key: http://devsilos.blogspot.com/2014/10/msb3268-while-targeting-aspnet-web-site.html
The author suggests:
aspnet_compiler for some reason does not take into account the .dll-s that reside under the Facade directory of 4.5 assemblies (C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\Facades).
It looks only under
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5
My extrapolation on that idea is that maybe the compiler doesn't take into account DDLs in the Facades directory if they're referenced by a third-party DLL rather than directly from your project.
The solution, as suggested by the author, was to find the DLLs matching assemblies mentioned in the MSB3268 warnings and copy them from Facades to its parent directory.
I think my problem/solution differed from the blog's in that it had nothing to do with the .NET Framework version targeted. It had only to do with whether the build server's compiler looked in the right places to resolve third-party DLLs' dependencies.
The problem caused about ten hours of frustration. I hope this helps someone else avoid that!
I have a web application which is made up of web forms. Slowly we are converting it over to MVC.
Last week I did a deploy to a testing environment and everything works as expected.
This week I made some changes to some ASPX/code behind files and also some user controls. I did a publish/deploy to testing and I receive an error when I browse to the site through IIS.
The error is:
Could not load file or assembly 'Microsoft.Owin, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e37' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Comparing the bin folder of the last good deploy, to the broken deploy, the only difference is the broken deploy has one extra file - Microsoft.Owin.Host.SystemWeb.dll
If I remove that file the website is able to load and function correctly.
The website has many projects and references, the root project (the one I right click > publish on) does not have a reference to this Microsoft.Owin.Host.SystemWeb.dll so it must be referenced from another project.
Is there any way to fix this error without having to delete the file from the bin folder? What is causing the error?
Also both bin folders have other Owin dll files.
Microsoft.Owin.dll
Microsoft.Owin.Security.Cookies.dll
Microsoft.Owin.Security.dll
Owin.dll
It sounds like one of your projects use the OWIN middleware. It also seems like someone may have tried to update the package and possibly did not do it properly. I would right-click on the solution and click "Manage NuGet Packages" and re-install the OWIN packages. If that does not work its likely a binding redirect issue that needs to be resolved in the web.config. You may also want to see if there are any OWIN references even being used in the project.
Background
I'm building a mobile app for an existing DNN 7 site; made by someone else who left a year ago or so. I had previously set up a WebApi module to handle authentication. Then I had the idea of setting up a class library to hold my DTO objects; since I would have to modify several existing modules to expose web methods and they'd have to interact with my app. So I created a class library threw in two classes and compiled. Added the dll reference to both my app and the web module and they have no issues building when referencing my objects. However, when I send a web request, from either my app or Postman chrome extension, to my module I get:
"Could not load file or assembly 'Elf.Web.Models, Version=1.0.6081.13955, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.",
My app doesn't seem to have issues creating and using the objects, just with the web module.
What I Tried/Checked
Properties I made sure both my class library and my web module were targeting the same framework; .NET Framework 4.5
Reference Property Copy Local is True and per Other Question
I tried manually editing my .csproj file to add the attribute Private to True under my reference. I even tried adding a binding redirect to my assembly.
Manual I also tried opening up my modules install zip tossing the class library dll into the bin folder, re-zip, and then installed to the dnn site. The problem persisted.
If anyone else has an idea of what could be an issue it'd be appreciated.
Putting the library dll in the bin folder of the installer zip file will not automatically put your library dll file into the bin folder of the DotNetNuke installation during install.
Add this to the installer .dnn file under the <components> node.
<component type="Assembly">
<assemblies>
<assembly>
<name>myLibrary.dll</name>
<path>bin</path>
</assembly>
</assemblies>
</component>
If you want the file to be added to the installer zip automatically, you have to make a reference in the ModulePackage.targets file.
<Copy SourceFiles="$(MSBuildDnnBinPath)\myLibrary.dll" DestinationFolder="$(MSBuildProjectDirectory)\Package\bin"/>
I have a C# WinForms Project which contains some WCF service definition files which I have created in the project by adding standard classes (not using Add Item > WCF Service).
The project contains some dependencies that require me to build the project for x86 processors.
If I edit the app.config file with the WCF Service Configuration Editor and try to use the "Create New Service ..." wizard, and then browse to the project EXE file (in the debug folder) I get an error, (which I've read is because I'm targeting the x86 processor):
Could not load file or assembly 'EXE_FILE_NAME' or one of its dependencies. An attempt was made to load a program with an incorrect format.
So, upon changing the target to All CPUs, compiling the project again, and then trying to create the service in the WCF Service Configuration Editor again, I now get a different error:
Could not load file or assembly 'SOLUTION_NAME, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
(To clarify, I CAN still compile the project when targeting all CPUs, but get an error at runtime due to a dependency)
Is anybody able to help me with this problem, so I can add the services defined in app.config file using the wizards in WCF Service Configuration Editor? (I think that if I add the services to the WCF Service Configuration Editor when targeting All CPUs I can make any modifications thereafter, regardless of the target)
When debugging, look at the exception detail. From what you've described my guess is you will an assembly loading error in the fusion log because the dependencies of the WCF service can't be satisfied by looking in the default locations.
Say for example you're referencing MrCritter.MyService.dll which defines a WCF service and has a dependency on something like log4net or nHibernate. As long as nothing from those dependencies is leaking into the WCF host (eg returning an ILog) yes you'll be able to compile fine but will get ReflectionTypeLoadException thrown when trying to instantiate the service class if those dependencies aren't somewhere it can find (eg in the executing directory, in GAC etc).