I have problems using costura fody with the latest build and standard small web services ( both asmx and wcf )
To test this. I build a simple asp.net project (hello world). I am using 2 simple class libraries as references.
[WebMethod] public string HelloWorld()
{
Class1 c1 = new Class1();
Class2 c2 = new Class2();
return c1.GetData() + c2.GetData();
}
This is working fine without Costura/Fody
Adding latest version of Costura/Fody from github:
When I run it now I get compile errors saying DotNetCompilerPlatform missing :
type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
warningLevel="4" compilerOptions="/langversion:default /nowarn:1659;1699;1701"/>
The DotNetCompilerPlatform dll is part of the embedded dll's.
Why is this ?
Trying the same with a WCF service I encounter a simular problem.
Regards
Related
As the title says, I'm having trouble getting Fody, and the plugin Fody.PropertyChanged, to work in .NET Core 3.0, or any .NET Core version. Reading the issues on the respective GitHub pages doesn't answer my question, nor am I able to find any relevant answers.
Once installed I cannot run my WPF project anymore and I am given the following error:
The target process exited without raising a CoreCLR started event.
Ensure that the target process is configured to use .NET Core.
This may be expected if the target process did not run on .NET Core.
The program '[21820] CalculationToolsApp.exe' has exited with code -2147450749 (0x80008083).
Any suggestions?
EDIT: I found out that I (maybe) cant use "Fody.Costura" with "Fody.PropertyChanged" like this in the FodyWeavers.xml file:
<Weavers>
<PropertyChanged />
<Costura />
</Weavers>
Which shouldn't be a problem because with .NET Core I can create a single file application anyway. Removing the Costura reference from the FodyWeavers.xml solved my problem!
It should work. Fody is compatible with .NET Standard.
Create a new WPF app using the WPF App (.NET Core) template in Visual Studio 2019 or using the dotnet new wpf command
Install the Fody and PropertyChanged.Fody NuGet packages
Add a file named "FodyWeavers.xml" with the following contents to the project:
<Weavers>
<PropertyChanged />
</Weavers>
Build
If you then decompile the assembly using a decompiler such as for example dotPeek, you should see the injected code as expected, e.g.:
public string GivenNames
{
// Method get_GivenNames with token 06000009
get
{
return this.<GivenNames>k__BackingField;
}
// Method set_GivenNames with token 0600000A
set
{
if (string.Equals(this.<GivenNames>k__BackingField, value, StringComparison.Ordinal))
return;
this.<GivenNames>k__BackingField = value;
this.<>OnPropertyChanged(<>PropertyChangedEventArgs.FullName);
this.<>OnPropertyChanged(<>PropertyChangedEventArgs.GivenNames);
}
}
Costura didnt work in wpf with .net core 3.1 for me either.
In .net core 3.1 you can use this instead:
Build -> publish -> create profile -> Edit "Configuration"
Target Runtime = win-x64 (or what ever target system you want, but NOT "portable")
expand "File Publish Options"
check: Produce single file
save
When you now choose build -> publish -> publish button it will create the single file.
It seems to be that they stopped the costura project because of the "Single-file executables" feature of .net core. Though this feature is still behind costura because you have to set a target runtime.
https://github.com/Fody/Costura/issues/442
In dotnet core 3 there are two new features
Single-file executables
Assembly linking
With these features included in the dotnet tool set, the value
proposition of Costura is greatly diminished. With that in mind I
think long term Costura should cease to be used as people transition
over.
Please comment with any input.
Plan:
disable issues
PR will still be accepted but only for bug fixes
add note to readme
add note to nuget description
write a warning in
update for .NET 5:
for .NET 5 and the current visual studio version 16.10.2 the wizard changed. I could not get this to work with the wizard anymore though i checked the options for single file etc.. But using the console worked: tools -> command line -> developer command prompt -> enter this:
dotnet publish -r win-x64 --self-contained true -p:PublishSingleFile=true -p:IncludeAllContentForSelfExtract=true
.NET 5 not compiling to single file executables
I need to launch a Universal Windows app from a WPF desktop application, in Windows 10. (Actually, I need to make calls against a Universal Windows App Service, but currently, I'm having problems just getting the app launched.)
Mostly, I'm trying to follow the example here: Launch a Universal App from a WPF App.
I'm able to follow the code to create his UniversalTargetApp without problems. But when I try to "Light up Windows 10 features" by adding his references to the .csproj file, I get errors.
He says to add this to the references ItemGroup:
<!-- Light up Windows 10 features -->
<Reference Include="System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Runtime.dll</HintPath>
</Reference>
<Reference Include="System.Runtime.WindowsRuntime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Runtime.WindowsRuntime.dll</HintPath>
</Reference>
<Reference Include="Windows">
<HintPath>C:\Program Files (x86)\Windows Kits\10\UnionMetadata\Windows.winmd</HintPath>
</Reference>
<!-- Light up Windows 10 features -->
But when I do, I get an error:
Multiple assemblies with equivalent identity have been imported: 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Runtime.dll' and 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.2\Facades\System.Runtime.dll'. Remove one of the duplicate references.
Clearly his method of adding references to the Universal Windows assemblies worked for his version of Windows 10, or he'd not have posted his example. But also clearly, this isn't the correct method for adding references to the Universal Windows assemblies, or it'd not have broken.
I've been trying to chase down how to properly reference the Universal Windows assemblies. All I've found is this:
How to call WinRT APIs in Windows 8 from C# Desktop Applications
But that dates to Windows 8, and I've not been able to make it work in Windows 10.
Can anyone tell me the proper method for referencing the Universal Windows assemblies, so that I can call Windows.System.Launcher.LaunchUriAsync(), create Windows.ApplicationModel.AppService.AppServiceConnections, etc.?
---Edited---
As per Mehrzad Chehraz's suggestion, I removed the first two references, leaving only the last. With that, I'm no longer getting the multiple reference error. But I am still not compiling.
The following code:
var options = new LauncherOptions { TargetApplicationPackageFamilyName = TargetPackageFamilyName };
bool success = await Launcher.LaunchUriAsync(uri, options);
Generates an error:
Error CS4036
'IAsyncOperation<LaunchQuerySupportStatus>' does not contain a definition for 'GetAwaiter' and no extension method 'GetAwaiter' accepting a first argument of type 'IAsyncOperation<LaunchQuerySupportStatus>' could be found
(are you missing a using directive for 'System'?)
Any ideas?
Remove the first two reference nodes, just keep the last one:
<!-- Light up Windows 10 features -->
<Reference Include="Windows">
<HintPath>C:\Program Files (x86)\Windows Kits\10\UnionMetadata\Windows.winmd</HintPath>
</Reference>
<!-- Light up Windows 10 features -->
Launcher.LaunchUriAsync works in this way but did not tested the AppServiceConnection.
I found part of an answer here:
Load UWP library into .NET Framework app
Step 1: Add to .csproj file
<PropertyGroup>
<TargetPlatformVersion>10.0</TargetPlatformVersion>
</PropertyGroup>
Step 2: Add reference to
C:\Program Files (x86)\Windows Kits\10\UnionMetadata\Windows.winmd
Step 3: Add reference to
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5\System.Runtime.WindowsRuntime.dll
I am developing my first project using WCF RIA services. I was able to build a small application and ran it successfuly on localhost. When tried to upload on a server, I got the following error when browsing it :
"Could not load file or assembly
'System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its
dependencies. The system cannot find the file specified"
I looked for this reference on my project and did not find it. I tried to add it from C:\Program Files (x86)\Microsoft SDKs\RIA Services\v1.0\Libraries\Server, but Visual Studio warns me:
You cant add a reference to
System.ServiceModel.DomainServices.Hosting.dll as it was not built
against the silverlight runtime.silverlight projects will only work
with silverlight assemblies
What should I do?
Thanks
Found the problem: on my .Web under references, found the needed dll.On properties, changed copy local to True
Every time I open existing or creating a new Windows Presentation Foundation project I get this error:
Could not load file or assembly 'Microsoft.Windows.Design.Extensibility, Version = 4.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.'
Cannot find file.
Tried to resolve using different guides or examples. But I am totally lost...
Hope you can help me!
Thanks, Big D!
I am using the Microsoft.Build.BuildEngine to build a number of projects. Projects that do not use Silverlight are building correctly while projects that do use Silverlight are not building. All of these projects (Silverlight and non-Silverlight) all build fine through Visual Studio 2008. I get the error message:
error CS0234: The type or namespace name 'SilverlightControls' does not exist in the
namespace 'System.Web.UI' (are you missing an assembly reference?)
I've added System.Web.Silverlight to the project that is doing the build using Microsoft.Build.BuildEngine. I am able to see that namespace in the project doing the build also (so it appears that the project doing the build does have access to System.Web.UI).
Any ideas on how I can avoid that error?
Turned up the verbosity on the build through VS2008 and compared to the log created from the Microsoft.Build.BuildEngine. It looks like the Microsoft.Build.BuildEngine is producing lines like:
Considered "c:\Program Files\Reference Assemblies\Microsoft\Framework
\v3.5\System.Web.Silverlight.dll", but it didn't exist.
It doesn't exist in that location, should it? There are actually a number of locations that it looks for that dll and doesn't find it. I added the reference by right clicking, add reference, .Net, add. There doesn't appear to be a System.Web.Silverlight.dll on my machine (which is odd because the project does compile using VS2008).
Comparing the possibly relevant sections of the two logs:
Microsoft.Build.BuildEngine
For SearchPath "{GAC}".
Considered "System.Web.Silverlight, Version=2.0.5.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL", which was not found in
the GAC.
Visual Studio 2008
System.Web.Silverlight, Version=2.0.5.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
Manually added System.Web.Silverlight to the path that the Microsoft.Build.BuildEngine was looking for it (coppied it from the output directory when I build the project via VS2008). This solved that problem, but I now get the following errors on the Silverlight components of the solution:
C:\Program Files\MSBuild\Microsoft\Silverlight
\v2.0\Microsoft.Silverlight.Common.targets(95,9): error : The Silverlight 2 SDK is not
installed.
Any ideas?
In the application that is running the Microsoft.Build.BuildEngine I changed the type of build from Any CPU to x86. This has now made the application be able to build the target as expected.
So you're programmatically building using the MSBuild APIs?
It may be useful to add an ILogger (e.g. that just prints to the console) to engine.Loggers, and compare the output with the output window in VS (after setting e.g. 'tools\options\project & solutions\build & run\msbuild output verbosity' to verbose)... seems like somehow the environment is causing assemblies to resolve differently?
Set build type of project to Any. This helps. Happy coding...