When you have a server side blazor app and you reference a razor class library directly (at the moment I am using dotnet5) it seems to automatically add the /_content/.bundle.scp.css by adding an #import to the .styles.css. This appears to work well enough at least in debug just by adding the reference and hitting F5.
I see conflicting documentation adding the links manually in many places and they are generally being added in the head as links, not as an #import. I am guessing this is maybe something that has changed since core3. I also have not figured out where the bundled files are supposed to "live" while you are still developing, when you publish you end up with a \wwwroot_content folder, but a development that appears not to exist on the filesystem and actually be mapped onto the \obj folders of the individual RCLs.
In the app I am currently working on the razor class libraries are loaded at run time, so this does not work automatically, for the time being I have the bundles referenced as individual links programmatically added in the head of the _host.cshtml after I copy them from the individual RCLs' obj<BuildFolder>\net5.0\ as that seems to be the only place they exist on disk. I am also serving them with an app.UseStaticFiles out of another folder since I am still unclear on how the inbuilt folders are meant to operate.
When I first figured out that the runtime load was an issue I was able to get confirmation there was not inbuilt support beyond direct references here https://github.com/dotnet/aspnetcore/issues/33284 and I started looking for how to re-implement the existing work-around more properly.
I would prefer this to work as similar to a directly referenced RCL as possible, but I am not finding any information on if the bundles are meant to be referenced globally at all times or conditionally, I do not see any obvious way to get them to be added as an #import programmatically, and I have no idea what the implications of trying to manually create the _content folder from the bundle files found in the various \obj folders would be.
How this is really supposed to work in development and when publishing? Is what i am doing even close or is there some glaring issue I will be encountering down the road?
Related
I am using the SDWebImage component in my project. Recently, I also decided to add MWPhotoBrowser (which uses SDWebImage). After installing MWPhotoBrowser I can no longer compile without receiving numerous errors. I am certain this is because the SDWebImage version is different across components I use.
As soon as I add the location of the header files for MWPhotoBrowser (which include SDWebImage) to my user search path I start getting these errors.
Any guidance / help as to how I can sandbox the libraries that MWPhotoBrowser needs so it doesn't affect the rest of my app ?
Rather than modifying any of the browser code I decided to eliminate my copies of SdWebimage and leverage those included in MWPhotobrowser instead. Not ideal, but I think the proper solution is to modify MWPhotobrowser to use these libraries as sub modules.
Not sure I'm using the right terminology, but if I have a website, and I make a change to one of the files, the underlying logic C#, whatever, do I have compile the whole application again before I deploy it?
How do I publish a small change?
You keep saying "the whole thing", but you don't really seem to understand what that means.
An MVC application is a Web Application project, which means that it's class files are compiled into an assembly. When you make a change to a class, the assembly that it's in must be recompiled (as well as any assemblies that are dependent upon it) and redeployed.
You don't have to recompile other assemblies that have not been changed, and you don't have to redeploy any unchanged files (like views or css or javascript).
If you have 100 pages, chances are, you probably going to split that up into several assemblies anyways. But even if you don't, it really doesn't take very long to compile even a 100 page web application (the pages themselves do not get compiled, it's only the .cs files). At most this should take 15-20 seconds on a medium powered workstation.
I think you're worrying about something that isn't really that big of a deal. You're probably more concerned about redeploying, but if you setup your publish system correctly, this is a single click, 10 second thing.
That depends on where you made the change.
If you made the change in a .cshtml or similar view file, or other content file (like javascript, css, images, etc.), just uploading the updated file will be sufficient.
If you changed a .cs (or vb, etc.) class however, you will need to recompile.
I am using Xcode 4.6.2 and i believe i am facing circular import issue in my project which i am unable to troubleshoot. Due to which i am not able to access few methods from another class using the class method. See my earlier question here.
Although i am using #class instead of #import in my header files, still i am unable to fine where exactly the problem is. Members of the StackOverflow have suggested me to use Xcode's built in functionality found under Product > Generate Output > Preprocessed File.
I have used this functionality and it generated a file that is too long to follow and i don't know what to do with it.
I have tried searching how to use it to troubleshoot the issue but couldn't find much help. Can anyone help me point out how to use "Preprocessed File" to troubleshoot my issue. Thanks!
I also went through your earlier question you have mentioned inside the question. You have said that you are using #class instead of #import in your header files, the methods that you are trying to access are declared in the header files and there are no typos of any kind.
In such cases, usually no body points this issue but i am going to do it anyway because i have faced such issues many times. You have probably created many copies of your project to work on each functionality and also keeping a working project.
When you do this, sometimes Xcode is still using the older copies of few files. That means it is still using the older copy of the TheFeedStore.h when the methods you are trying to access were not declared by you.
How to solve this problem is very simple. Go to the file from which you are trying to access the methods and the files in which these methods are declared.
In the Utilities section on the right hand side, check the location and full path under "Identity and Type" area.
First check the names of the project, if it is different from the project name that you are working on, that means Xcode is still pulling the old copies of the files from the previous revision of your project. See the blue arrows where the project name is 13SampleMoreRequests in my case.
If this name is same as your project name, then my answer does not solve your problem. If its different, you should use the new copies of the file by browsing the new location using the sign that is pointed out by red arrow.
Once you browse and use the new files, your problem will be solved and you will be able to access the methods. If you still can't, copy these files, delete from the project and then add them again and you won't face this problem.
Hope this helps!
We have been using Yii for building web applications. Once in a while, themes comes to our discussion table.
But, if we have a web application and we wish to change the look and feel only, we may, as well, change the public_html folder, since the structure will be similar.
The only point we see on having themes is for those cases where we may want to dynamically (user choice by clicking on a "change layout button") change the look and feel of an application.
Does anyone uses themes for any other proposes, or configurations?
We use themes to great effect. We operate 6 sites using as single instance of a Yii application. The theme is then selected based on the domain name.
Yes we could have just used 6 different application folders and served them separately. This comes with several advantages though, which you've probably already dismissed if they're not relevant to you, but here they are:
Shared code, updates and maintenance are far easier
Adding a new theme is much cleaner IMO (just a new theme folder rather than a whole application directory)
Global assets, which are then overridden easily in the theme, rather than wiping over them completely, you'r expanding them.
Shared Cache, the whole application caches to a single directory, view cache, data cache etc.
Shared Assets directory, assets are only published once ( although this could in theory be set up in a copied environment)
I much prefer this set up, it looks far cleaner just to override rather than overwrite. Plus really, I can't think of a reason why copying the whole directory would be better than this method, yes there are issues in theming that have to be worked out, but copying the whole source doesn't solve them.
My application has a plugin system that allows my users to write their own plugins that get loaded at runtime. Usually this is fine but in some cases two plugins use the same libraries that will cause a collision between those two.
Example:
Plugin A wants to use TouchJSON for working with JSON and thus the creator adds the TouchJSON code to the plugin source and it gets compiled and linked into the plugin binary. Later Plugin B also wants to use that same library and does exactly the same. Now when my app loads these two different plugins it detects this and spits out an warning like this:
Class CJSONScanner is implemented in
both [path_to_plugin_a] and
[path_to_plugin_b]. One of the two
will be used. Which one is undefined.
Since my app just loads plugins and makes sure they conform to a certain protocol I have no control over which plugins are loaded and if two or more use the same library.
As long as both plugins use the exact same version of the library this will probably work but as soon as the API changes in one plugin a bunch of problems will arise.
Is there anything I can do about this?
The bundle loading system provides no mean to pacifically resolve name conflicts. In fact, we're told to ensure ourselves that the problem doesn't happen, rather than what to do if it happens. (Obviously, in your case, that's not possible).
You could file a bug report with this issue.
If this is absolutely critical to your application, you may want to have bundles live in separate processes and use some kind of IPC, possibly NSDistantObject, to pass the data from your program to the plugin hosts. However, I'm fairly sure this is a bag of hurt, so if you don't have very clearly-defined interfaces that allow for distribution into different processes, it might be quite an undertaking.
In a single-process model, the only way to deal with this is to ensure that the shared code (more precisely, the shared Objective-C classes) is loaded once. There are two ways to do this:
Put the shared code in a framework.
Put the shared code in a loadable bundle, and load the bundle when the plug-in is loaded if the relevant classes aren’t already available (check using NSClassFromString()). The client code would also have to use NSClassFromString() rather than referring to classes directly.
Of course, if you aren’t in control of the plug-ins you can’t enforce either of these schemes. The best you can do is provide appropriate guidelines and possibly infrastructure; for instance, in the second case the loading could be handled by the application, perhaps by specifying a class to check for and the name of an embedded bundle to load if it isn’t available in the plug-in’s Info.plist.