Setting AssemblyCulture causing "The view found at .. was not created" error

[MartijnRasenberg]

we had the "The view found at .. was not created" error on a project. After a vast amount of hours searching we found that a change in the AssemblyInfo.cs caused the problem.
We had set
[assembly: AssemblyCulture("")]
to
[assembly: AssemblyCulture("nl-NL")]

reverting that change fixed the problem.
Any idea how this would affect modelsbuilder in this way?

[zpqrtbnk]

Not immediately. Going to try to reproduce.

[zpqrtbnk]

Planning to spend a bit of time on this - can you just tell me on which assembly are you changing the AssemblyCulture attribute?

[MartijnRasenberg]

It was not on a specific assembly but in the AssemblyInfo.cs file (in the Properties folder of the VS project).

[zpqrtbnk]

ok so I guess... my question is... what VS project ? ;-) how do you generate models (pure live, dll, etc)?

[MartijnRasenberg]

The settings (from dev section in Umbraco backoffice) on localhost:

ModelsBuilder is enabled, with the following configuration:

• The models factory is enabled.
• The API is installed and enabled.
  The API endpoint is open on this server.
• External tools such as Visual Studio cannot use the API.
• No models mode is specified: models will not be generated.
• Models namespace is Umbraco.Web.PublishedContentModels.
• Static mixin getters are enabled. The pattern for getters is "Get{0}".
• Tracking of out-of-date models is not enabled.

[zpqrtbnk]

so you are generating the models via the custom tool and the API, is that it?
and the assembly culture attribute... is on the VS project which builds the model?

[MartijnRasenberg]

Yes, that is it (both).

[zpqrtbnk]

OK now making more sense to me, going to investigate.

What version of Umbraco / Models Builder is this by the way?

Unrelated question. These lines:

The API is installed and enabled.
The API endpoint is open on this server.
External tools such as Visual Studio cannot use the API.

They don't make sense to me, as the code does:

if (!config.ApiServer)
  sb.Append("External tools such as Visual Studio <em>cannot</em> use the API");
else
  sb.Append("<span style=\"color:orange;font-weight:bold;\">The API endpoint is open on this server</span>");

So I'm not quite sure how the API endpoint can be reported as open and external tools as not being able to connect, at the same time. Is this for real or a copy/paste error?

[zpqrtbnk]

OK, from AssemblyCultureAttribute on MS docs:

The attribute is used by compilers to distinguish between a main assembly and a satellite assembly. A main assembly contains code and the neutral culture's resources. A satellite assembly contains only resources for a particular culture, as in [assembly:AssemblyCultureAttribute("de")]. Putting this attribute on an assembly and using something other than the empty string ("") for the culture name will make this assembly look like a satellite assembly, rather than a main assembly that contains executable code. Labeling a traditional code library with this attribute will break it, because no other code will be able to find the library's entry points at runtime.

So... seems to be the expected behavior that setting this attribute breaks the library. Why were you doing this exactly?

[MartijnRasenberg]

What version of Umbraco / Models Builder is this by the way?
Umbraco version 7.12.4 assembly: 1.0.6879.21982
Umbraco Models Builder dll has version 3.0.10.102

This is a screenshot from the site

[zpqrtbnk]

Ah, the screenshot makes sense, thanks!

[MartijnRasenberg]

OK, from AssemblyCultureAttribute on MS docs:

The attribute is used by compilers to distinguish between a main assembly and a satellite assembly. A main assembly contains code and the neutral culture's resources. A satellite assembly contains only resources for a particular culture, as in [assembly:AssemblyCultureAttribute("de")]. Putting this attribute on an assembly and using something other than the empty string ("") for the culture name will make this assembly look like a satellite assembly, rather than a main assembly that contains executable code. Labeling a traditional code library with this attribute will break it, because no other code will be able to find the library's entry points at runtime.

So... seems to be the expected behavior that setting this attribute breaks the library. Why were you doing this exactly?

It was a mistake made by one of the developers...
But if this is expected behaviour than I suppose the solution is not to do it :-)

[zpqrtbnk]

aha exactly :-)

[MartijnRasenberg]

Thanks for the check!