vb.net -> C# *.aspx files

[B0R1K]

.aspx files should change CodeBehind tag vale from ".vb" -> "*.cs"

[B0R1K]

and Language="VB" to Language="C#"

[GrahamTheCoder]

Yep, seems sensible to me. I haven't really tested aspx conversion so far. If you see any other changes related to aspx feel free to add them here too.

[EricStG]

The aspx template can also contain VB/C# code within tags <% %>. Those blocks would also need translation.

[genixg]

Also *.ascx files please!)

[GrahamTheCoder]

When I investigated ".asp" files I can't remember if I checked for aspx/ascx. But just linking to my comment at the time for reference:
#160 (comment)

In particular: https://docs.microsoft.com/en-us/dotnet/api/system.web.compilation.buildprovider?redirectedfrom=MSDN&view=netframework-4.7.2 may be useful in some way perhaps

[GrahamTheCoder]

I've just had a brief look into this. It turns out that Roslyn creates a separate project within the solution object for each aspx file.
The project contains a single document with some boilerplate, then a section for each <% %> tag (1 indexed) like:
<h2><%: Title.ToLower() + "2" %></h2> gets transformed to

#ExternalSource("C:\Users\gph77\source\repos\CodeConverterTests\VbAspNetWebApplication1\Contact.aspx",1)
__o =  Title.ToLower() + "2" 
#End ExternalSource

Assigning to the __o object seems to just mean it was in an "output" tag like <%: or <%=.

So we'll need to:

• Discover and convert the aspx projects relevant to the documents being converted (project.FilePath still matches the relevant project). When something other than a whole project/solution is converted, relying on the names Contact.aspx being related to Contact.aspx.vb is probably sufficient at least initially.
  • For simplicity, support converting the ExternalSource directive
• Have an output mapper - Roslyn/VS has something similar built in (see Enhanced C#: a friendly hello dotnet/roslyn#11324 (comment)) so that it can apply code fixes:
  • Parses the existing aspx file from disk to some extent (possibly assisted by some other part of VS/roslyn) to locate each code block
  • Creates the output with the header language updated, and each <% %> tag block's contents replaced with the corresponding ExternalSource section from the converted code

[Yozer]

Few things from what I noticed:

1. We can't pick a converter just by looking at the file extension like we do it right now:

   CodeConverter/Vsix/CodeConversion.cs

   Lines 336 to 339 in 7a4bcd1

   	public static bool IsVBFileName(string fileName)
   	{
   	switch (Path.GetExtension(fileName).ToLower()) {
   	case ".vb":

   
   I'm pretty sure this feature be implemented only for VB->C# but we probably want to avoid running C#->C# conversion on aspx. We could look at child files to see if there is a designer.vb or just .vb with code-behind.
2. Running converter on designer file is pointless as any hacks converter did there it will be overridden quite fast. The designer file is automatically regenerated when you save aspx file.
   I know that this VS plugin can regenerate aspx designer file, maybe it's possible to do the same in Converter after converting aspx file.
   https://github.com/ulrichb/Roflcopter/blob/7166412afd759ecd2618c234825720dc4f7c226c/Src/Roflcopter.Plugin/UpdateAspDesignerFiles/UpdateAspDesignerFileService.cs
3. Regarding the hacks. It's quite common to use Handles keyword to wire events from controls.
   Designer: Protected WithEvents wbtn_FilterRoomAttributes As WebButton
   Code behind: Private Sub SmthOnClick(sender As Object, e As EventArgs) Handles wbtn_FilterRoomAttributes.Click
   Currently Converter would add some extra code to wire events for a field that is declared in designer page. It works until someone regenerates the designer.
   As the solution, we could wire the events in the OnInit method (not sure if doing that in constructor works, field can be null).

[GrahamTheCoder]

1) Yep we'd definitely need to check/refine the behaviour there. I think it's possible to get the nested files, and the menu may even already correctly appear because of them.
2/3) For winforms designers, this turned out not to be true. The previous auto-generated file is an input to the next autogeneration, so it was necessary to get it right. The nice side effect is that the event generation code works fine so long as the naming is careful. I assume aspx is the same, but could be wrong. The linked extension looks like it uses a JetBrains library at a quick glance, but there may be a Roslyn equivalent that's useful (perhaps in the winforms case too).

[Yozer]

Sadly from my observations, it doesn't work like that for aspx/ascx files. If you open a markup file and save it VS will override these changes.

Not sure if the naming is not right (looks fine on the diff above) or VS is just completely regenerating this designer file.

Even adding one letter to comment will override it:

[Yozer]

Few more observations:

1. This hidden project for aspx/ascx files is only created when you actually open the file in VS. Makes sense - if you have a few thousands of them in solution it would be extremely inefficient to parse them all.
   It probably means that command-line too won't be able to convert aspx/ascx files correctly.

2. The mapping has to have some kind of logic because I found that the order of expressions <% %> in my aspx file doesn't match the order of #ExternalSource. Literally, the first expression on my page was mapped to id 6

[GrahamTheCoder]

Good finds - not great news for an already difficult feature, but good to know in advance