Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parameter property generate error CS0120 #88

Closed
kccarter76 opened this issue Aug 12, 2020 · 9 comments · May be fixed by #85
Closed

parameter property generate error CS0120 #88

kccarter76 opened this issue Aug 12, 2020 · 9 comments · May be fixed by #85

Comments

@kccarter76
Copy link

CS0120
GeneratedTextTransformation.txt

after looking at the code that was generated it looks like the field and the property need to be declared static

kccarter76 added a commit to SubSonic-Core/SubSonic.Core.TextTemplating that referenced this issue Aug 12, 2020
kccarter76 added a commit to SubSonic-Core/SubSonic.Core.TextTemplating that referenced this issue Aug 12, 2020
@mhutch
Copy link
Contributor

mhutch commented Nov 30, 2020

I don't follow why these properties should be static? It would make more sense to me that they would be specific to the template instance - that way, runtime text templates could have multiple instances without risk of accidentally mixing up parameters (especially when using multiple threads).

@kccarter76
Copy link
Author

I did try to implement them not being static and the engine was not able to reference the property. making the read only property static was the simplest solution to making it work.

@mhutch
Copy link
Contributor

mhutch commented Dec 1, 2020

Unless I'm misreading something, the template code appears to be trying to initialize a const string with an instance property value and then use that constant from a static property?

IMO this is a problem with the template code, not the generated code.

@mhutch
Copy link
Contributor

mhutch commented Dec 1, 2020

I don't see any parameters in those templates though?

@kccarter76
Copy link
Author

settings.ttinclude line 1.

the the vsix template replaces $connectionKey$ with a property name ,that is renamed in a identifiable way that can be compiled in code, to a connection in visual studio data explorer. the transformation host retrieves the connection string from visual studio and stores it as a parameter to be used. in the template.

@mhutch
Copy link
Contributor

mhutch commented Dec 1, 2020

I see. So the pattern here is an include that adds a parameter to the template class, and then defines a nested static helper class that wants to access that parameter from the template class instance. The template class also has to be aware of this and initialize the settings class by assigning it the host value.

I can think of a few alternatives:

  • instead of having a nested settings class with helper properties, have the include just add those helper properties directly to the template class
  • create an instance of the settings class instance from the the template class e.g. var settings = new Settings(Host, connectionString)
  • implement the parameter property explicitly, or skip it entirely and have the helper class resolve the parameter from the host or session directly

@kccarter76
Copy link
Author

assuming, I am remembering the code correctly that sounds about right. what you are suggesting is in line with dependency injection pattern. That would solve the problem in a way that applicable for everyone. If I have the time to experiment I look into it. currently working on other projects that actually put bread on the table.

@mhutch
Copy link
Contributor

mhutch commented Dec 3, 2020

Closing this for now as making these properties static would cause other problems and there are ways to structure a template so that the static properties are not needed.

@mhutch mhutch closed this as completed Dec 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants