I have a small Visual studio add-in that walks down active project and insert code to every method.
My target project has web service reference and it created a bunch of auto-generated refenrece files that I do not care about.
Is there a way to detect whether a projectitem is autogen file?
The project file has tag under but ProjectItem.Properties doesn’t have it.
Thanks
Is there a way to do this 100% reliably? I don't think so. The only way I've ever been able to tell if a file is autogenerated or not is by its content or by its filename.
Often, generated code files in newer versions of (what I know) C# have a ".g." within their names. This is not written in stone or guaranteed (I think windows forms and other older generators use ".Designer."), but it can be used as an indication.
If you look through different autogenerated code, you'll see there are a number of different ways it can be marked. There is no specific way that is universal. For example, autogenerated wire-up code in WPF codebehind files (the hidden InitializeComponent() method resides there) contains a partial class definition marked with the System.CodeDom.Compiler.GeneratedCodeAttribute and the methods are all marked with the System.Diagnostics.DebuggerNonUserCodeAttribute.
The first attribute resides on the class, so it may show up when inspecting the code via EnvDTE methods. You might have to resort to reading the file in raw and looking for that attribute.
Even this isn't enough information, as different code generators mark their code differently. Type safe DataSets and EF generated code mark their generated code with a comment at the top of the file
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30319.551
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
What now?
Unless you explore all the different ways autogenerated code is marked, and handle them all, there isn't any way (unless I'm missing something!) you can guarantee skipping these files. You have to ask yourself if it is worth the effort.
Related
I'm modifying a code written in c++ in order to add several features required by my company. I need to modify as less as possible this code, because it's a public code get from a Git repository, and we want to avoid to deviate from the original source code in case we need to synchronize our code with possible new versions in the future.
In this code, a structure is initialized with a call to std::memset. And I had need to add a shared pointer to this structure.
I notice no issue about that, the code compiles, links and works as expected, and I get even no warnings while the compilation.
But is it safe to achieve that this way? May a std::shared_ptr be correctly initialized if it is part of a structure initialized with std::memset? Or are side effects or hazardous issues which prevent to do that?
VS2015 shows how many references there are to a class.
However if the class is started by WebApplication.Run the references are not shown.
The highlighted code does get executed when the application is run.
Is there any way to get the reference count for the Configure method?
Here are two reasons ;)
The Startup Class is invoked by reflection (it does not implement an interface)
I doubt that code pieces outside of your local source code will influence the reference count. So even if somewhere deep in WebApplication.Run the Configure method is invoked (assuming directly over some magic interface), the reference code will not rise. Make sense, otherwise the counter for string would have overflow ;)
I am writing a CodeGenerator. The string output is later on mixed with user code.
In order to be able to make changes to my generated code after the user edits the file, I have to make sure my generated parts are not editable.
I am currently not sure how to achieve this behaviour..
If I would be able to track which line correlates to which CodeDomObject and vice versa I could tell my TextEditor to mark Lines as read only.
But at this Point I have two problems.
I don't know how to keep track.
I am not sure if my solution ( which I am not able to implement... ) is
clean. There would be a lot of overhead, because I have to find out
which object is generated and which not. I could do so by comparing a
generated CodeDomTree with the actual Tree and marking the diffs as
UserObjects.
I don't know if this solution is practical in your environment but this is handled using partial classes where required in Visual Studio.
An example would be Windows Forms where the visual designer is responsible for creating source code to reproduce the form at runtime but the developer is expected to add event handling code to the class.
By having the developer's code in a separate source file it doesn't get overwritten when changes are made in the designer.
Of course, this won't help you if you need to have a single source file for your class.
I have an application that is multilingual. I'm using the out-of-the-box .Net features for this. Each language has its own file in the App_GlobalResources (see iamge below)
In the code behind what is better?
GetGlobalResourceObject("LocalizedText", "ErrorOccured")
Resources.LocalizedText.ErrorOccured
The 2nd one uses less code and it's type safe, it will return an error during compile time and not run time.
alt text http://img340.imageshack.us/img340/5562/langl.gif
These are the advantages of each approach:
Advantages of GetGlobalResourceObject (and GetLocalResourceObject):
You can specify a particular culture instead of using the CurrentCulture.
You can use a late-bound expression (i.e. a string) to decide which resource to load. This is useful if you can't know ahead of time which resource you will need to load.
It works with any resource provider type. For example, it works not only with the built-in default RESX-based provider but it'll work the same against a database-based provider.
Advantages of strongly-typed RESX types:
You get compile-time errors if you access a resource that doesn't exist.
You get Intellisense while working on the project.
So, as with many "which is best" questions, the answer is: It depends! Choose the one that has advantages that will benefit your particular scenarios the most.
So use the second one, if you know up-front what the resource file and key will be.
The GetGlobalResourceObject() method is useful if you don't know what the resource file or (more likely) the key will be at compile time.
I am developing an application that has a repeater that will use dynamic templates for each row based on the underlying DataItem (in this case a product). What I would like to do is have some sort of XML file that will store which templates are to be used with which templates, and then use a default template if there is not one specified for the product. My product catalog does not contain a particularly large number of products, but having to open and parse an XML file for each row would almost certainly have adverse performance effects. What I would like to do is have the ASP.net engine compile the entries in the XML file into some sort of global collection that can easily be accessed when needed. Ideally, the application would be able to determine when I have made changes to the file and would automatically recompile the collection and restart the application if necessary. If my understanding is correct, this is already how the engine deals with the web.config file.
Does anyone know if an approach like this is possible, and how I might be able to accomplish it?
Thanks,
Mike
Well you could likely open and parse the XML file on each page load without any significantly adverse performance issues. Toss the result in a page-level collection and for each repeater row, read from that. This will at least prevent you from having to manage a global collection with a file change update dependency.
I do use XML in similar ways, albeit for mostly non-critical company Intranet type applications, so I'd certainly say your approach isn't too awful. :) In my specific cases, I have ultimately put the XML in a global application level object, with the trade off being that I have to manually restart the application to re-load the XML, should it change.
If you do want to tackle your ideal scenario, I would look to store the XML templates in the Cache object and set up a CacheDependency on the XML file.