I'm using ASP.Net Core 5.0 for a web application in which I'm using ViewComponents. The ViewComponent classes are defined in another project. The main project has too many views so I added:
<PropertyGroup>
<RazorCompileOnBuild>false</RazorCompileOnBuild>
<RazorCompileOnPublish>true</RazorCompileOnPublish>
</PropertyGroup>
in the .csproj file, reducing the compile time from 120 seconds to 10. But then I faced a problem. The ViewComponents are not detected anymore in my main project. They don't appear in view results and even not suggested by intellisense.
The ViewComponent:
[ViewComponent(Name = "EntityForm")]
public class EntityFormViewComponent : ViewComponent
{
public async Task<IViewComponentResult> InvokeAsync()
{
if (ViewData.ContainsKey("ViewMode") && ((ViewMode)ViewData["ViewMode"] == ViewMode.Create || (ViewMode)ViewData["ViewMode"] == ViewMode.Edit || (ViewMode)ViewData["ViewMode"] == ViewMode.Delete))
return View("EntityForm");
else
return View("EntityGrid");
}
}
The project hierarchy:
None of the ViewComponents shown in the image work with RazorCompileOnBuild set to false.
ViewComponent usage:
<vc:entity-form />
I try to use the newest C# 10 features in Visual Studio 2022 Preview 3. The compiler does not recognize the new keywords required or field. global using seems to work.
public required string Name { get; init; }
public DateTime HiredDate{ get; init => field = value.Date(); }
Null parameter checking doesn't compile:
public void NullParameterCheck(string arg!!) { ... }
I also tried to set the language version to preview in the .csproj:
<LangVersion>preview</LangVersion>
Is there any setting I missed?
Finally I found part of the solution. I have to add
<LangVersion>preview</LangVersion>
<EnablePreviewFeatures>true</EnablePreviewFeatures>
to the .csproj file. Null parameter checks work, but not required and field.
this is what I use in .csproj file:
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<LangVersion>preview</LangVersion>
<EnablePreviewFeatures>true</EnablePreviewFeatures>
<GenerateRequiresPreviewFeaturesAttribute>true</GenerateRequiresPreviewFeaturesAttribute>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>
I have an installer (.msi) project that uses Wix Toolset v3.14. For some reason it is never up-to-date -- i.e. building it again always produces some activity (C:\Program Files (x86)\WiX Toolset v3.14\bin\Light.exe gets called, but not candle.exe). Is there any way to track down and fix the cause?
Here is what I observe when detailed output is ON:
Target "ReadPreviousBindInputsAndBuiltOutputs" in file "C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix.targets" from project "<my-project>" (target "Link" depends on it):
Task "ReadLinesFromFile"
Task Parameter:File=obj\x64\Debug\<my-project>.wixproj.BindContentsFileListen-us.txt
Output Item(s):
_BindInputs=
C:\Users\<me>\AppData\Local\Temp\a5uljxg1\MergeId.418703\api_ms_win_core_console_l1_1_0.dll.AF4EABEE_4589_3789_BA0A_C83A71662E1D
...
Done building target "ReadPreviousBindInputsAndBuiltOutputs" in project "<my-project>.wixproj".
Target "Link" in file "C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix.targets" from project "<my-project>.wixproj" (target "CompileAndLink" depends on it):
Building target "Link" completely.
Input file "C:\Users\<me>\AppData\Local\Temp\a5uljxg1\MergeId.418703\api_ms_win_core_console_l1_1_0.dll.AF4EABEE_4589_3789_BA0A_C83A71662E1D" does not exist.
...
<and here it executes Light.exe>
So, it looks like it reads BindContentsFileListen-us.txt and expects it to contain files that were inputs during last build run. But, unfortunately some of these files were generated in temporary folder and got wiped out (presumably during last build) and since they don't exist anymore -- Link step is re-executed. I observe this pattern every time I press F7, only number in MergeId.418703 gets changed every time (looks like process id to me).
UPDATE: this is a known (and pretty old) issue. As of now it is planned to be fixed in WiX v4.0.
I have hit the same issue, and the only information I found apart from this question was a pretty unhelpful mail thread from 2013 (1, 2) and an issue from the same era.
Troubleshooting
Reading through the logs and Wix's source code shows that the bugs occurs as follows:
light.exe, the linker, receives all of the object (.wixobj) files it should combine, some of them referencing the .msm merge module's file path.
light.exe uses a combination of mergemod.dll's IMsmMerge::ExtractCAB and cabinet.dll's ::FDICopy (through their own winterop.dll) to extract the contents of the merge module to a temporary path:
// Binder.cs:5612, ProcessMergeModules
// extract the module cabinet, then explode all of the files to a temp directory
string moduleCabPath = String.Concat(this.TempFilesLocation, Path.DirectorySeparatorChar, safeMergeId, ".module.cab");
merge.ExtractCAB(moduleCabPath);
string mergeIdPath = String.Concat(this.TempFilesLocation, Path.DirectorySeparatorChar, "MergeId.", safeMergeId);
Directory.CreateDirectory(mergeIdPath);
using (WixExtractCab extractCab = new WixExtractCab())
{
try
{
extractCab.Extract(moduleCabPath, mergeIdPath);
}
// [...]
}
At the same time, the contents of the merge module are inserted among the other input files in the fileRows collection:
// Binder.cs:5517, ProcessMergeModules
// NOTE: this is very tricky - the merge module file rows are not added to the
// file table because they should not be created via idt import. Instead, these
// rows are created by merging in the actual modules
FileRow fileRow = new FileRow(null, this.core.TableDefinitions["File"]);
// [...]
fileRow.Source = String.Concat(this.TempFilesLocation, Path.DirectorySeparatorChar, "MergeId.", wixMergeRow.Number.ToString(CultureInfo.InvariantCulture.NumberFormat), Path.DirectorySeparatorChar, record[1]);
FileRow collidingFileRow = fileRows[fileRow.File];
FileRow collidingModuleFileRow = (FileRow)uniqueModuleFileIdentifiers[fileRow.File];
if (null == collidingFileRow && null == collidingModuleFileRow)
{
fileRows.Add(fileRow);
// keep track of file identifiers in this merge module
uniqueModuleFileIdentifiers.Add(fileRow.File, fileRow);
}
// [...]
fileRows ends up being written to the <project_name>BindContentsFileList<culture>.txt file inside the intermediate directory, including the temporary (and randomly named) files extracted from the merge module:
// Binder.cs:7346
private void CreateContentsFile(string path, FileRowCollection fileRows)
{
string directory = Path.GetDirectoryName(path);
if (!Directory.Exists(directory))
{
Directory.CreateDirectory(directory);
}
using (StreamWriter contents = new StreamWriter(path, false))
{
foreach (FileRow fileRow in fileRows)
{
contents.WriteLine(fileRow.Source);
}
}
}
During the next build, the ReadPreviousBindInputsAndBuiltOutputs target from wix2010.targets reads the file into the #(_BindInputs) item group. This item group is then listed as input to the Link target. Since the temporary files have since disappeared, the target is always considered out-of-date and re-run, generating an new set of temporary files that get listed in BindContentsFileList, and so on.
Workaround
An actual fix would be to patch Wix so that merge modules discoverd in .wixobj files are listed in BindContentsFileList, and files extracted from them during linking aren't. Unfortunately I wasn't able to make Wix's source code compile, and can't be bothered to go through its distribution process. Hence, here is the workaround I have implemented.
Removing temporary files from the input list
This is done using a custom target which slots in-between ReadPreviousBindInputsAndBuiltOutputs and Link and filters #(_BindInputs) to remove whatever is under %temp%.
<Target
Name="RemoveTempFilesFromBindInputs"
DependsOnTargets="ReadPreviousBindInputsAndBuiltOutputs"
BeforeTargets="Link"
>
<PropertyGroup>
<!-- This includes a final backslash, so we can use StartsWith. -->
<TemporaryDirectory>$([System.IO.Path]::GetTempPath())</TemporaryDirectory>
</PropertyGroup>
<ItemGroup>
<_BindInputs
Remove="#(_BindInputs)"
Condition="$([System.String]::new('%(FullPath)').StartsWith('$(TemporaryDirectory)'))"
/>
</ItemGroup>
</Target>
At that point, Link triggers only when actual input files change. Success! However, changes to the .msm files are not detected. This might be good enough a solution anyway, since merge modules are generally static. Otherwise...
Detecting changes to merge modules
The main hurdle is that the only reference to the .msm file is within a .wxs source file, so we need to bridge the gap between that and MSBuild. There are a couple ways that can be used, such as parsing the .wixobj to fish out the WixMerge tables. However, I already had code in place to generate Wix code, so I went that way, lifting the merge modules into an MSBuild item group and using a custom task to generate a .wxs file referencing them in a feature. Full code below:
<Target
Name="GenerateMsmFragment"
BeforeTargets="GenerateCompileWithObjectPath"
Inputs="#(MsmFiles)"
Outputs="$(IntermediateOutputPath)MsmFiles.wxs"
>
<GenerateMsmFragment
MsmFiles="#(MsmFiles)"
FeatureName="MsmFiles"
MediaId="2"
OutputFile="$(IntermediateOutputPath)MsmFiles.wxs"
>
<Output TaskParameter="OutputFile" ItemName="Compile" />
</GenerateMsmFragment>
</Target>
// GenerateMsmFragment.cs
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Runtime.InteropServices;
using System.Text;
using System.Text.RegularExpressions;
using System.Xml;
namespace tasks
{
[ComVisible(false)]
public class GenerateMsmFragment : Task
{
[Required]
public ITaskItem[] MsmFiles { get; set; }
[Required]
public string FeatureName { get; set; }
[Required]
public string MediaId { get; set; }
[Output]
public ITaskItem OutputFile { get; set; }
public override bool Execute()
{
var xmlns = "http://schemas.microsoft.com/wix/2006/wi";
var outputXml = new XmlDocument();
outputXml.AppendChild(outputXml.CreateXmlDeclaration("1.0", "utf-8", null));
var fragmentElem = outputXml
.AppendElement("Wix", xmlns)
.AppendElement("Fragment", xmlns);
{
var mediaElem = fragmentElem.AppendElement("Media", xmlns);
mediaElem.SetAttribute("Id", MediaId);
mediaElem.SetAttribute("Cabinet", "MsmFiles.cab");
mediaElem.SetAttribute("EmbedCab", "yes");
}
{
var directoryRefElem = fragmentElem.AppendElement("DirectoryRef", xmlns);
directoryRefElem.SetAttribute("Id", "TARGETDIR");
var featureElem = fragmentElem.AppendElement("Feature", xmlns);
featureElem.SetAttribute("Id", FeatureName);
featureElem.SetAttribute("Title", "Imported MSM files");
featureElem.SetAttribute("AllowAdvertise", "no");
featureElem.SetAttribute("Display", "hidden");
featureElem.SetAttribute("Level", "1");
foreach (var msmFilePath in MsmFiles.Select(i => i.ItemSpec)) {
var mergeElem = directoryRefElem.AppendElement("Merge", xmlns);
mergeElem.SetAttribute("Id", msmFilePath);
mergeElem.SetAttribute("SourceFile", msmFilePath);
mergeElem.SetAttribute("DiskId", MediaId);
mergeElem.SetAttribute("Language", "0");
featureElem
.AppendElement("MergeRef", xmlns)
.SetAttribute("Id", msmFilePath);
}
}
Directory.CreateDirectory(Path.GetDirectoryName(OutputFile.GetMetadata("FullPath")));
outputXml.Save(OutputFile.GetMetadata("FullPath"));
return true;
}
}
}
// XmlExt.cs
using System.Xml;
namespace nrm
{
public static class XmlExt
{
public static XmlElement AppendElement(this XmlDocument element, string qualifiedName, string namespaceURI)
{
var newElement = element.CreateElement(qualifiedName, namespaceURI);
element.AppendChild(newElement);
return newElement;
}
public static XmlElement AppendElement(this XmlNode element, string qualifiedName, string namespaceURI)
{
var newElement = element.OwnerDocument.CreateElement(qualifiedName, namespaceURI);
element.AppendChild(newElement);
return newElement;
}
}
}
And voilà, working up-to-date detection for merge modules.
I'm trying to migrate my PCL project to the new "net standard" but for now I failed.
Currently I got the following exception :
System.MissingMethodException: 'Method not found: 'Void Xamarin.Forms.Xaml.Internals.SimpleValueTargetProvider..ctor(System.Object[], System.Object, Xamarin.Forms.Internals.INameScope)'.'
It happend directly from the 'InitializeComponent' of a page where I have the following xaml tag:
<Image Source="{ns_uc:ImageResource i_home_on.png}"/>
where the 'ImageResource' is an extension marker, this one works like a charm in my PCL project. Here is a part of the definition :
public class ImageResourceExtension : IMarkupExtension
But this class is not called from my new .NET Standard project !
In the .csproj I have the following references, it should be enough ?
<PackageReference Include="System.ComponentModel" Version="4.3.0" />
<PackageReference Include="Xamarin.Forms" Version="3.4.0.1008975" />
So, if someone have an idea because I have already spend 2 days in this migration, without success :-(
BTW, it seems I'm not alone : https://forums.xamarin.com/discussion/101999/cant-use-imarkupextension-in-a-net-standard-library
Thanks for your help
1.System.ComponentModel is a NuGet package in some NetStandard versions.Try to install it if it doesn't exist.
2.You can use <Image Source="myImage.png"/> directly instead of using IMarkupExtension in .net standard project.
3.The implement of ImageResourceExtension maybe different in PCL project and .net standard 2.0 project. Here is an implement in official demo you can refer:
[ContentProperty("Source")]
class ImageResourceExtension : IMarkupExtension<ImageSource>
{
public string Source { set; get; }
public ImageSource ProvideValue(IServiceProvider serviceProvider)
{
if (String.IsNullOrEmpty(Source))
{
IXmlLineInfoProvider lineInfoProvider = serviceProvider.GetService(typeof(IXmlLineInfoProvider)) as IXmlLineInfoProvider;
IXmlLineInfo lineInfo = (lineInfoProvider != null) ? lineInfoProvider.XmlLineInfo : new XmlLineInfo();
throw new XamlParseException("ImageResourceExtension requires Source property to be set", lineInfo);
}
string assemblyName = GetType().GetTypeInfo().Assembly.GetName().Name;
return ImageSource.FromResource(assemblyName + "." + Source, typeof(ImageResourceExtension).GetTypeInfo().Assembly);
}
object IMarkupExtension.ProvideValue(IServiceProvider serviceProvider)
{
return (this as IMarkupExtension<ImageSource>).ProvideValue(serviceProvider);
}
}
You can refer the demo below to fix your project.
Refer:Demo of ImageResourceExtension
Documents of Markup Extensions
I would follow James Montemagno's steps:
https://montemagno.com/how-to-convert-a-pcl-library-to-net-standard-and-keep-git-history/
I followed this video from the Xamarin show:
https://channel9.msdn.com/Shows/XamarinShow/Snack-Pack-15-Upgrading-to-XamarinForms-to-NET-Standard
I tried it on my own the first go around and failed miserably. The second go around I followed the instructions from the video exactly and everything worked.
I created a small extension for the EF designer that adds a new property to the property window. I did this using a vsix project (new project -> c# -> extensibility -> vsix project). When I hit F5 the experimental VS instance starts up. I create a new project, add an entity data model and add an entity. However, my break points never get hit and I don't see the property. Any ideas as to what I might be doing wrong?
public class AggregateRootValue
{
internal static XName AggregateRootElementName = XName.Get("AggregateRoot", "http://efex");
private readonly XElement _property;
private readonly PropertyExtensionContext _context;
public AggregateRootValue(XElement parent, PropertyExtensionContext context)
{
_property = parent;
_context = context;
}
[DisplayName("Aggregate Root")]
[Description("Determines if an entity is an Aggregate Root")]
[Category("Extensions")]
[DefaultValue(true)]
public string AggregateRoot
{
get
{
XElement child = _property.Element(AggregateRootElementName);
return (child == null) ? bool.TrueString : child.Value;
}
set
{
using (EntityDesignerChangeScope scope = _context.CreateChangeScope("Set AggregateRoot"))
{
var element = _property.Element(AggregateRootElementName);
if (element == null)
_property.Add(new XElement(AggregateRootElementName, value));
else
element.SetValue(value);
scope.Complete();
}
}
}
}
[Export(typeof(IEntityDesignerExtendedProperty))]
[EntityDesignerExtendedProperty(EntityDesignerSelection.ConceptualModelEntityType)]
public class AggregateRootFactory : IEntityDesignerExtendedProperty
{
public object CreateProperty(XElement element, PropertyExtensionContext context)
{
var edmXName = XName.Get("Key", "http://schemas.microsoft.com/ado/2008/09/edm");
var keys = element.Parent.Element(edmXName).Elements().Select(e => e.Attribute("Name").Value);
if (keys.Contains(element.Attribute("Name").Value))
return new AggregateRootValue(element, context);
return null;
}
}
EDIT: I put the code on Github: https://github.com/devlife/Sandbox
EDIT: After Adding the MEF component to the manifest as suggested, the extension still never loads. Here is a picture of the manifest:
So the answer, as it turns out, is in how I setup my project. I put both classes inside the project which produces the VSIX file. By simply moving those classes into another project and setting that project as the MEF Component in the manifest (and thus copying the assembly) it worked like a charm!
For VS2012, it is only needed to add Solution as MEF component also. Just add whole solution as MEF component also.
Then it works surprisingly fine.
It seems the dll built by your project isn't automatically included in the generated VSIX package, and VS2013 doesn't give you options through the IDE to change this (that I can work out, anyway).
You have to manually open the project file and alter the XML. The property to change is IncludeAssemblyInVSIXContainer.
Seen here: How to include VSIX output in it's package?