How to build Autofac from sources? I found only one deprecated wiki page.
I've tried to launch go.cmd (.NET Framework 4.0), but it failed with errors:
C:\Autofac\Autofac.csproj" (default target) (4) ->
(CoreCompile target) ->
Builder\MetadataConfiguration.cs(28,14): error CS0234: The type or namespace name 'Linq' does not exist in the namespace 'System' (are you missing an assembly reference?)
[C:\Autofac\Core\Source\Autofac\Autofac.csproj] Features\LazyDependencies\LazyWithMetadataRegistrationSource.cs(28,14): error CS0234: The type or namespace name 'Linq' does not exist in the namespace 'System' (are you missing an assembly reference?)
What I am doing wrong?
Autofac 3.0 has been updated so the core Autofac.dll is a Portable Class Library that targets multiple platforms. Portable Class Libraries don't have references to System assemblies so the missing System.Core reference is correct - it shouldn't be there. You should be able to use the Portable Class Library with .NET 4... or with Windows Store or Windows Phone 8 apps. I strongly recommend not modifying the references for the .csproj. You'll break that compatibility and inadvertently change the target profiles.
The wiki page on building from source has been deprecated because the instructions for building are in a readme right in the root of the source code. (That's mentioned on that deprecated wiki page - first line.) It explains all the prerequisite tools and commands required. If you follow the information in there, you should not have to modify anything to get the source to build.
If you aren't modifying the sources, I'm not sure why you'd need to rebuild the source to target .NET 4 specifically. It should just work. If you see something that isn't working, please file an issue about it on the Autofac site.
If you are modifying the source, the readme in there should get you building without messing with the project references.
It looks like the Autofac.csproj does not include a reference to system.core. See also this question and this bugreport. So can you try to add this to the Autofac.csproj file:
<ItemGroup>
<Reference Include="System.Core" />
</ItemGroup>
Possibly you also have to add other references, such as System.
Related
I'm trying to update a Unity project that was built in version 2019.4.01f (Intel, LTS) to version 2021.3.10f (Apple Silicon, LTS). The reason is that I need update the In App Purchases package from Unity because Google Play requires that I update the billing library.
I already tried a bunch of options, but I keep getting errors. If I generate the GoogleTangle I get error CS0103: The name 'Obfuscator' does not exist in the current context. If I don't generate new tangles or copy the old tangles from the old path to the new one (according to the steps from here), I get other errors like: error CS0234: The type or namespace name 'Purchasing' does not exist in the namespace 'UnityEngine' (are you missing an assembly reference?) and other similar errors. If I manually add some of the Purchasing assembly definitions I see no improvements.
Did anyone tried doing this recently?
The reason for the error was an Assembly definition. In order to allow PlayMode tests access to some of the game code I had an Assembly Definition in Assets/Scripts that was referenced in the PlayMode Assembly.
After removing the tests and the Assembly definition, the errors went away except for a new one that lets you know that you need to initialise Unity Services before initialising Purchasing (that's how Unity Purchasing works now).
This was a quick fix. The correct solution would be to keep the tests and use Assembly definitions in the folders that contain the code that PlayMode tests need to access. That will most probably lead to the need of Assembly definitions in other folders as well and at this point the code structure must be built in such a way that you don't get cyclic references between Assembly definitions.
We use VS 2017 and consume NuGet packages the old way. We do not use PackageReference as of yet.
When a NuGet package reference is updated through the NuGet Manager in VS, the respective assembly binding redirect is not updated automatically - we have to do it manually.
So, I suppose it is up to the package to take care of it through the tools\install.ps1 script. Now, I think I know how to implement it, but I do not want to invent the wheel. Surely the code already exists somewhere, but where?
Clarification
Our application is strongly signed and it targets .NET 4.5.2 currently (soon to be upgraded to 4.7.2). We use packages.config.
I need to explain what is going on. There are three players on the field:
A tool - DbUpgrade
The tool plugin Api - DbUpgradeApi
An implementation of the plugin Api - LogDbUpgradeProgress
Let us inspect the DbUpgradeApi package. 3 versions of it are relevant to us:
The version against which LogDbUpgradeProgress is compiled - A
The version against which DbUpgrade is compiled - B
The latest version of DbUpgradeApi - C
The DbUpgrade tool loads the plugin LogDbUpgradeProgress at runtime. The binding redirects are needed, because A is not the same as B (and because the code is signed, nothing to do here currently)
If C is higher than B, then we should update the reference to DbUpgradeApi in DbUpgrade. But doing so must be accompanied with updating the binding redirect. And this is the essence of this question.
Ok, so I just spent the last hour testing, and I didn't need to do anything that I consider special for binding redirects to work.
But first, are you sure you need binding redirects? .NET Core doesn't need it. If you're using .NET Framework, but with a project using PackageReference, then it's resolved at build time, your app.config doesn't need the binding redirect in the version that's checked in with your code, but when you build and check the [your exe name].config file it does have the binding redirects. Also, binding redirects only matter when your assembly has strong naming. If you didn't sign your assembly, then binding redirect isn't needed.
Here are the steps that I took to create a reproduction of getting binding redirects in a console app using packages.config.
Create an empty folder to start with. I used dotnet new sln, dotnet net nugetconfig to generate a new sln and nuget.config file. I edited the nuget.config file to add the folder localFeed as a source, and set the globalPackagesFolder to gpf so I didn't pollute my real global packages folder with test packages. Also created a strong name key with sn -k snk.snk.
Create first test classlib. dotnet new classlib -n someLib. I edited Class1.cs to change the class name to SomeClass and added a property that retusns the value "Version 1". Used Visual Studio to set snk.snk as the signing key. dotnet pack to generate V1 of the package. I then edited SomeClass to change the message to "Version 2" and then ran dotnet pack /p:version=2.0.0. Finally, used nuget.exe add -source localFeed someLib\bin\Debug\someLib.1.0.0.nupkg and again for v2 of the nupkg.
Create the second test classlib, dotnet new classlib -n anotherLib and set the signing key to snk.snk. Changed Class1.cs to AnotherClass and added a property public string Message => new someLib.SomeClass().Message;. Added a reference to someLib version 1 in the csproj, then built, packed and used nuget.exe to add the nupkg to localFeed.
Opened Visual Studio and created a .NET Framework console app. Added a reference to anotherLib, which automatically brought in v1 of someLib. Upgraded the reference of someLib to v2, and confirmed that packages.config now has a binding redirect for someLib.
Created another .NET Framework console app and did the same as step 3, but this time using PackageReference instead of packages.config. The project app.config doesn't have binding redirects, but the .config file in the bin folder after build does.
edit: perhaps an important part to understanding NuGet/MSBuild binding redirect behaviour is the following: In both steps 3 and 4, if I add a reference only to anotherLib, then no binding redirect is created because all assembles that reference someLib reference the same version. Only by making my console app reference a different version of someLib than anotherLib uses, then the binding redirect is created.
In an app with plugins, the building the app assembly won't have a binding redirect, because it's the only assembly in the compile command line that uses the plugin contract dll, so no conflict to need a binding redirect. When the plugin assembly is built, only the plugin depends on the plugin contract dll, so again no conflict so no binding redirect. If you copy all the dlls into a single folder, then there can be a conflict in the required version, but this is a deployment time issue, not a build/compile time issue, so build tools may not help. One way to resolve this would be to add a reference to the plugin project from the app assembly. This way at compile time the build tools can see that two different versions of the plugin contract dll is used, so a binding redirect can be created. This only works if you build the app assembly. If the app is just a binary that you're given, then changing the binding redirects becomes a deployment time responsibility, so development/build tools may not help.
Does anyone know how I can get the V3 version of ServiceStack.Client off Nuget? This wiki page appears to suggest that they should be there: https://github.com/ServiceStackV3/ServiceStackV3
I need to create a new project to interact with a legacy v3 ServiceStack implementation. I can't upgrade the existing API, but the JsonServiceClient in the new v4 is not compatible. I've imported the contracts DLL from our legacy API, which is causing the incompatibility issue.
The exact error is:
Error 105 The type 'ServiceStack.ServiceHost.IReturn' is defined in an assembly that is not referenced. You must add a reference to assembly 'ServiceStack.Interfaces, Version=3.9.48.0, Culture=neutral, PublicKeyToken=null'. D:\Projects\Adactus.Pulse\Main\Solutions\Integration\Mulesoft\SupplierIntegration\ScmtProcessor\InitialInstructionProcessor.cs 231 17 ScmtProcessor
Have they been moved by chance to a different nuget package name (i.e. the BSD version)? Or do I need to manually start copying DLL references around?
No they haven't been moved, you can see all the NuGet package versions listed on NuGet:
https://www.nuget.org/packages/ServiceStack/
https://www.nuget.org/packages/ServiceStack.Common/
You'll need to download the exact v3.9.48 packages you need, which the v3 page you linked to shows an example of:
https://github.com/ServiceStackV3/ServiceStackV3
I'm trying to publish a web site.
The publication works perfectly, but when I try to access the address it returns me the following error:
Parser Error Message: Could not load
file or assembly
'Microsoft.Web.Helpers' or one of its
dependencies. This assembly is built
by a runtime newer than the currently
loaded runtime and cannot be loaded.
Source Error:
Line 293:
Line 294:
Line 295: Line 296:
Line
297:
Source File:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\Config\web.config
Line: 295
Assembly Load Trace: The following
information can be helpful to
determine why the assembly
'Microsoft.Web.Helpers' could not be
loaded.
WRN: Assembly binding logging is
turned OFF. To enable assembly bind
failure logging, set the registry
value
[HKLM\Software\Microsoft\Fusion!EnableLog]
(DWORD) to 1. Note: There is some
performance penalty associated with
assembly bind failure logging. To turn
this feature off, remove the registry
value
[HKLM\Software\Microsoft\Fusion!EnableLog].
This does not happen when I'm running on the local site.
The application was developed and Sql Server WebMatrix Compac 4
If you read the error message it says "Could not load file or assembly 'Microsoft.Web.Helpers' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded." If you then look at the version of the ASP.NET that this site is attempting to run under, it is ASP.NET Version:2.0.50727.4209.
Web Pages and the Web Helpers library need Version 4.0. Make sure the site targets the correct version of ASP.NET.
For missing assemblies a simple solution is to just bundle them with your project.
Go to your project -> references -> find this microsoft web helpers ref -> open the properties panel and set Copy Local to True
Edit: Also try setting assembly binding logging.
I suspect that your web.config is fine and that there is an assembly missing from your deployment.
You probably have to include microsoft.web.helpers in your deployment package or simply copy it to the bin folder.
You might find that there are other assemblies missing but you should be able to pick them off one by one.
There is a previous question Hosting WebMatrix Page
that lists all of the dlls you have to deploy and also suggests using Webdeploy
I am created pre-generated views for my EDMX using VS 2008, .NET 3.5 and Entity framework.
I have generated using the t4 templates mentioned here and got my mymodel.views.cs file. It's around 40 mb is size.
Added the views.cs file to my web application and my web service. When i build the apps, the webservice would build without any error and i can get the WS to work. But, the build fails in the website with the error
error CS0234: The type or namespace
name 'Mapping' does not exist in the
namespace 'System.Data' (are you
missing an assembly reference?)
The System.Data assembly is referenced in both the projects and the version denotes .NET 2.0. Suspect something trivial i am missing here, but still clueless.
Any pointers would help!
Add a reference to System.Data.Entity.dll, which contains the System.Data.Mapping namespace.