I have a problem, and I can't find a solution. This question is maybe already solved a couple of times, but it's hard to find a working solution for my constellation.
I'm using Blazor wasm 3.2.0-preview3.20168.3'. My goal is to move my components in a shared library to use it across my projects.
The problem is my components are not going to be rendered if I'm moving them into a shared library, so the tag <alert><alert/> is not resolved. The browser displays <alert><alert/>.
If they are in the main project, everything is working fine.
In the main project in "_Imports.razor" the dependencies are imported
#using BlazingWebShared.Services
#using BlazingWebShared.Component
My library .csproj looks more or less like this (not including comments etc):
<Project Sdk="Microsoft.NET.Sdk.Razor">
<PropertyGroup>
<TargetFramework>netstandard2.1</TargetFramework>
<AddRazorSupportForMvc>true</AddRazorSupportForMvc>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="3.2.0-preview3.20168.3" />
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.Build" Version="3.2.0-preview3.20168.3" PrivateAssets="all" />
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="3.2.0-preview3.20168.3" PrivateAssets="all" />
<PackageReference Include="Microsoft.AspNetCore.Blazor.HttpClient" Version="3.2.0-preview3.20168.3" />
</ItemGroup>
</Project>
Does someone have an idea what I'm doing wrong? Or can someone share a library I can use as a blueprint?
Thank you very much for your time and help.
The line
<AddRazorSupportForMvc>true</AddRazorSupportForMvc>
tells me that you checked "support for pages and views" when you created your Razor Class Library (RCL). Make a new one without that check. You get a very different project setup with or without that checkmark. Amongst other things it will target the wrong platform, core 3.x instead of standard 2.x
And don't forget that you also have to import the .css and maybe .js files from the RCL into your _Host.razor or Index.cshtml . See this answer for that.
Related
I followed the Angular2 Quick start example and used live-server to run it. It works fine.
I created then a web site in IIS and set the virtual directory to the directory where I have the index.html file. When I run the website I get the following error. The error happens when the IIS tries to server app.ts.
How can run the Angular2 app in IIS?
The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map.
UPDATE:
Solution: I created a new web.config file and added the following snippet of code to add the MIME type. This will be used by the IIS as the local web app settings.
<configuration>
<system.webServer>
<staticContent>
<mimeMap fileExtension=".ts" mimeType="application/x-typescript" />
</staticContent>
</system.webServer>
</configuration>
By convention, it is not advised to directly serve TypeScript (.ts) files. This is why IIS doesn't enable this by default. The quickstart tutorial also explicitely mentions this halfway the page, on section What's wrong with this?, where it states the following:
We were up and running in a hurry and we could explore Angular in this manner for quite some time. For a number of reasons this isn't a good approach for building an application:
Transpiling TypeScript in the browser becomes tediously slow when our app grows beyond a few files. We certainly won't do that in production. We should learn to compile locally and push the generated JavaScript to the server. We'll need some tools for that.
So if you take a couple of minutes more and finish the tutorial, it'll work out for you just fine without having to bother with IIS configuration.
That being said, if you truly want it, it is possible. Like mentioned in other comments, you can add a MIME type for .ts files in IIS. In the SO question What's the MIME-Type of TypeScript it is explained as well.
try to register a .ts mime type
Add a MIME Type (IIS 7)
Also, this SO seems like a good explanation
I am using the code from the
Microsoft ASP.NET Identity Samples 2.1.0-alpha1
There's one area of the code that I do not understand and that is the web.config entry below:
<appSettings>
<add key="owin:AppStartup" value="IdentitySample.Startup,WebApplication3" />
My code does work without this but I am wondering if I should have something like this.
Can anyone explain to me what this does?
Basically this tells OWIN what method to execute on the application start. And IdentitySample.Startup method contains code that bootstraps your application.
You can specify this class via an attribute [assembly: OwinStartup(typeof(StartupDemo.TestStartup))] if you wish.
But this one is web.config so it can be changed for different deployment strategies without recompiling the project.
See more details in documentation.
I'm trying to import a common msbuild file to my current msbuild project.
The reason I'm doing this is because all the things in the common msbuild file are used in several projects so I don't want to write them over and over again.
What I want to do is import that project from a weblink, so I have a shared place with all developers together where the common file is under versioning control.
What I tried:
<Import Project="http://git/api/rest/repositories/52OWsIr0K1/content?path=common.build.msbuild" />
This works fine in firefox, as it would download the specified file.
I use this solution to import common build tasks in gradle, so I thought it might work in msbuild too.
However, I just get an error that the specified file can't be found :/ Does anyone have an idea on how to use this the way I want to?
I'd like to ask you for best practices with developing with Liferay SDK.
I have the SDK downloaded, I have Eclipse ready, it works, I can create new portlets and run local Liferay instance to test it.
Here is my situation - all the source code I have is in the Eclipse workspace, currently it is only portlets what I'm working on.
Liferay SDK I have in completely different location than workspace. Let's say ~/dev/liferay_sdk.
Eclipse workspace is located in ~/workspace.
At the beggining, it was not working like that. Eclipse from some reason can't find or use Liferay SDK. When I changed "Project validation" in Eclipse/Liferay configuration to "Ignore" the "Liferay Plugin SDK is not valid", it started to work without problems.
Next problem happend when it comes to need to build a WAR for example.
In the portlet directory in the workspace is present "build.xml" file. But inside it refers to another xml file, which should be located one directory up, and this one refers to more thing in relatively location and so on.
In short, it assumes that you have the portlets etc, inside the Liferay SDK.
Like "~/dev/liferay_sdk/portlets".
My question is, Am I wrong completely, or could you suggest me the best practices with this?
I don't want to mix SDK and the code, it sounds wrong to me.
Thanks for help!
I think, the best practice is still when your portlet projects are located inside the Liferay Plugins SDK directory. That way you can take all the advantages of the Liferay IDE plugin for Eclipse, for example. Because as far as I understand Liferay IDE will not allowed you to have portlet projects in another location. It's pretty easy to import projects to Eclipse from inside the Liferay SDK directory, and that's not problem.
But I also faced the same sort of problem when tried to save portlet project to the Git repository. Possible solutions with symbolic links didn't work correctly on every system. Thus I slightly modified the build.xml file to be able to run ant tasks from any directory. For portlets it was something like that:
<project name="your-portlet" basedir="." default="deploy">
<property file="build.properties" />
<property name="project.dir" value="${liferay.sdk.home}" />
<import file="${project.dir}/build-common-plugin.xml" />
</project>
Notice that you should define property "liferay.sdk.home" in build.properties and it should be path to the Liferay Plugins SDK.
As for other types of Liferay plugins (themes, hooks, etc.) you should import another build file for building that type of plugin. For example, for themes it will be:
<import file="${project.dir}/themes/build-common-theme.xml" />
Hope you'll get the idea. :) But think twice before doing something like that.
Liferay plugins are developed inside the Liferay Plugins SDK, its called SDK for a very good reason.
I don't find anything wrong with the plugins-SDK and the code tied togather, below are few reasons why:
If you see the liferay repository of plugins on github, you would find all the sample portlets and other plugins are stored in their respective folders inside plugins-SDK.
So if you want to develop liferay plugins (with or without IDE), the best practice (the only efficient way I think) is to have the projects created inside the respective folders of plugins SDK like portlet projects inside portlets folder, hook project inside hooks folder etc.
If you have used Liferay IDE when you create a plugin project (Liferay project) in this IDE you specify the SDK and the server runtime and what it does is it creates the project inside your Plugins SDK and copies the .settings, .classpath & .project file inside the project created. It does not create the project inside your workspace as eclipse normally does for other projects.
Hope I have managed explain it clearly and this was what you wanted.
I'm already quite happy with the other answers, this could have been distributed through comments at those, but a separate answer gives some more structuring options:
As Prakash says, it's not really bad to do that. In addition to his answer, you do not need to have your code in the workspace directory. Eclipse is happy to put it anywhere in the filesystem - thus while you work with Eclipse you don't even care where exactly your code is (and as you check it into version control - right? - you actually never need to care.
If you want to use Liferay's OOTB ant scripts: They are geared towards exactly the setup you describe: Work in the SDK directory. It's actually not bad, but if you don't like it, you just have to accept that you can't work with build.xml without changing it (like Artem suggests).
Another option is to use maven - this also bypasses the sdk (and the Liferay IDE integration), so you're again free to put your sourcecode whereever you like and let maven do the rest.
I can imagine some rather esoteric and rare issues with Artem's suggestion (like referring to custom parent themes when you imply some relative position) but I consider that as extremely minor, so if that works for you: Go ahead. Just keep in mind that you don't fulfill the basic assumptions that the SDK makes, so you might have to change things that violate the assumptions. I can't imagine this being too hard if you keep this in mind.
Of course, what you miss with that solution is the neat handling of including build.${username}.properties - you'll have to have your own build.properties that define ${liferay.sdk.home}. If you're not working in a team, that's ok. Otherwise you'll have to invent this yourself (and code it) or rely on global parameters to be configured with every team member.
How can i configure the Common.Logging->log4net which log4net built with a different .snk file?
when i want to build the Project it looks for log4net that has a PublicKeyToken=1b44e1d426115821, but mine is different. I tried to identify my log4net assembly as below. that doesn't work.
<configSections>
<sectionGroup name="common">
<section name="logging" type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
</sectionGroup>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net,Version=1.2.10.0, Culture=neutral, PublicKeyToken=XXXXXXXXXXXX"/>
thanks
Have you made Common.Logging reference your version of log4net and then rebuilt it (Common.Logging)?
I suspect that you will have to open the Common.Logging.Log4Net project and change the reference to log4net from the log4net that Common.Logging redistributes to your log4net. I think that you should then be able to rebuild Common.Logging and you should also be able to reference your version of log4net in the configuration.
UPDATE...
Another idea would be to write your own log4net factory adapter. Just use the exact source code from Commom.Logging's log4net factory adapter project. There is not really much code there. In your project, reference your own log4net. Configure Common.Logging to use your factory adapter. I don't know that this option is any more or less attractive than rebuilding Commom.Logging with your version of log4net, but I thought I would mention it anyway.