I'm using ASP.NET 4.0 and have resource files (like labels.en-EN.resx) and manage them using the ResourceManager object.
How can I check if there is no translation file for a specific culture? (Besides checking if the compiled localization dll exists in the BIN folder)
Related
When using selfhost .Net Core 2.x, all the build artifacts are statically served by default, since the default directory is the same place as the binary/exe.
This means if one knows the names of the dlls, they can just request
them at /Whatever.dll, or they can also get any config files by name,
i.e. appSettings.
If you change things so that that the root directory is different or that directory is not in the VFS, /metadata stops working.
Is it possible to have /metadata work, but not allow the service's dlls etc to be statically served?
I have tried restricting the paths. This will keep settings / dlls / exes from serving, but the /metadata page will come up completely blank.
The /metadata page isn't related to the static file directory location, you may have caused a Startup Exception that's impacted how it works. If you can put together a stand-alone project on GitHub which shows the issue I can investigate.
Only extensions in Config.AllowFileExtensions can be served, you can remove .dll from being served with:
Config.AllowFileExtensions.Remove("dll");
.exe aren't servable by default, if you can download them you might be downloading them with .NET Core's static file handler instead.
It's common practice to have the WebRoot outside of the project root which for .NET Core is typically /wwwroot.
edit: Updated suggestion to remove the badness.
What I ended up doing at first was to add a .UseWebRoot() onto the
builder, then later switched from the selfhost ServiceStack template
to the web template per Mythz's suggestion. The web template was
set up in a way that solved my problem.
Thanks again.
I am using asp.net core application and in my application Resources.resx file properties Build Action is set to Embedded Resource and Copy to output directory is set to copy always and from my virtual directory i am editing that file but changes are not getting reflected.
Is there any way to get this done?
I have an azure web role with Azure SDK 2.3.
My web site project website has web.config, which gets copied to bin/debug/website.dll.config properly during build.
But Azure SDK totally fails to include this DLL in the cspkg which causes my role OnStart to fail, since it depends on binding redirects in the web.config to load the correct version of the Azure runtime assemblies. Anyone got any bright idea why cspack isn't including this file and what to do about it?
web.config files are never copied as projectNAme.dll.config!
Only application.config files are copied this way. And yes, for Web Roles nothing beside the regular web.config are automatically copied.
You have to name your configuration file following the name of your main application assembly (i.e. website.dll.config) and then explicitly mark it with Copy Always in the properties panel, section Copy to output folder. Thus the file will be included into the web role package.
IIS 7.5, Framework v4.0
Error: The file web.sitemap required by XmlSiteMapProvider does not exist.
Solutions Appreciated
You need to create web.sitemap file for your site.
This is from MSDN:
The simplest way to create a site map is to create an XML file named Web.sitemap that organizes the
pages in the site hierarchically. This site map is automatically picked up by the default site-map
provider for ASP.NET.
The Web.sitemap file must be located in the application root directory, though it can reference other
site-map providers, or other site-map files in other directories as long as those files are in the same
application.
For more information you may check this article: ASP.NET Site Maps
Is it possible to have two Web Parts with the same DLL, but two .webpart files, deployed in Sharepoint at the same time?
Background :
I am developing an application that will generate a ".cab" file containing a Web Part (ASP.NET 2.0 Web Part). After that, the user should be able to deploy this ".cab" file in a in a SharePoint server.
My application already includes the DLL of a Web Part. The "behavior" of this Web Part depends on the properties of the ".webpart" file which will be generated at runtime by my application (its content will change depending on certain user choices)
After generating the ".webpart" file, it packages it to a ".cab" file along a Manifest.xml and the DLL.
Imagine that the user creates two "cab" files using my application. And he wants to deploy them into SharePoint.
To test this, I create this two ".cab" files with my app, and in SharePoint I execute:
$> STSADM.EXE -o addwppack <cab filename #1>
$> STSADM.EXE -o addwppack <cab filename #2>
$> STSADM.EXE -o deletewppack <cab filename #1>
After the execution of the third command, the Web Part #2 doesn't have the DLL.
When I installed Web Part #2, SharePoint override the DLL file of Web part #1
The problem here is that the DLL of both files is copied to same location. That location is the Assembly name of DLL. That assembly name cannot be changed without recompiling again (I think).
Is there anyway to deploy two cab files independently, even if they share the same DLL?
You could split your application in 2 parts: a 'library' that contains only your dll. And something that deploys the .webpart file only.
Users must always keep the 'library' part installed..
Also, you might want to look at alternatives from installing a 'wpppack'.. the .webpart file is nothing more than a file in a library in your sites.. may be easier to add that than to install a .cab on the server.
This shouldn't be an issue at all. A .webpart file simply points to a class within an assembly, and provides the configuration values for a specific instance of that class. If you want to have multiple configurations of your webpart available from the webpart gallery, you would go about it by uploading multiple .webpart files which reference the same class. For example, every instance of the listview webpart can be exported to a .webpart file, but they are all using the same webpart class. Check this blog posting for more info on the contents of the .webpart file.