Trying to host my webapi on the production machine but there, all DI services remains null. And I get the NullReferenceException everywhere I try to access the services variable inside the Startup class.
The exception points the line where I'm adding the context. services.AddDbContext(x=>x.UseMySql(...)). If I remove this line, then It jumps to the services.AddAutoMapper() and so on.
Note that this occurs only on the production machine. Everything is pretty cool on my dev machine.
Am I missing a config file (appsetting.json and appsetting.dev.json are both identicall) OR is there another cause?
Really had hard time solving this issue! I had to navigate to the folder and run dotnet myApi.dll instead of using the path dotnet /var/apps/myapi/myApi.dll.
Not sure but It seems like the cli is looking for a config file in the directory from within it's being called
Related
I've an an .exe file (WebHost with signalR application) that, when ran as a user, is running fine. I wanted to turn it into a windows service with the following command, sc.exe create myService start=auto DisplayName=MyCustomService binPath="D:\bla\bla\bla\MyCustomService.exe" runs fine, the service is created. Then when I want to start the service, it reaches a timeout with an error 1053. However is I run manually D:\bla\bla\bla\MyCustomService.exe, it launches pretty quickly and without any error. Privileges are sufficient, there is no dependencies issue, I'm wondering what am I doing wrong here ? Is it related to the use of AspNetCore ? SignalR ? I doubt it...
EDIT : the .exe is a published version with -c Release
I've fix the issue, this is dumb but could not find the answer after hours of research (it was mentioned in #CoreTech comment) : the application was not defined as a windows service (even if it is a WebHostApp).
So in my program's Main method, I just added to the HostBuilder .UseWindowsService() (Thanks to a co-worker). And now, no problem.
I download visual studio code for mac today. I tried to create a simple asp.net 5 web application following these instructions https://code.visualstudio.com/Docs/ASPnet5
When I open my web application folder in visual studio, it says I need to run a restore command.
I ran the dnu restore command just like the instructions tell me but it seems to always fail.
I receive different errors every time I run it. But most of them are like this one:
CACHE https://www.nuget.org/api/v2/package/System.Threading/4.0.10-beta-22816
SharpCompress.Common.ArchiveException: Could not find Zip file Directory at the end of the file. File may be corrupted.
Restore failed
There is a stack trace as well, but for brevity sake I'll omit it for now
Has anyone experienced this?
Try dnu restore --no-cache.
You may also need to remove previously downloaded files - check ~/.dnx/packages. I removed all files from that folder some time before trying the above. Also, see the comments below, if ~/.dnx/runtimes contains unexpected versions removing them may also work. Note that the current runtime version can be controlled using dnvm.
I never saw the NullReference exception, but I was getting the SharpCompress.Common.ArchiveException. I suspect there was a mismatch from what dnu thought was the cache state with the actual cache state (maybe something timed out the first time or something).
I'm using web deploy to deploy an MVC4 application using EF5 code first. I made a publish profile called "development" that uses web deploy for application and database using the 'Execute Code First Migrations' checkbox to run migrations on application startup. The publishing worked great for a while. At some point I added a new publish profile called "test" to deploy to another server, which uses the ftp method of deploy and no automatic migrations. This works fine too. However, when I tried to use my old "development" publish profile again, VS changes the settings automatically to the dbDacFx way ('Update database' checkbox instead of 'Execute Code First Migrations') and I can't get it back to the way it was.
There were some other changes to the project while using the 'Test' profile, but nothing that seems to me like it could cause this. Does anyone know why VS thinks my project doesn't use code first anymore?
Since asking this question, I've run into this problem several more times in multiple versions of MVC and EF (all code first though of cource). When it happens, don't save the changes to your publish profile, make sure you are on the 'debug' build configuration, clean solution and rebuild solution. And if all that fails, restart Visual Studio and try again.
So far, this has always solved the problem for me.
Here is the right answer - is solved the problem for me.
Just rename your connection string exactly as your DbContext, e.g.
public ApplicationDbContext()
: base("Vocabulary.Domain.ApplicationDbContext", throwIfV1Schema: false)
{
}
Note that name should include namespace like "Vocabulary.Domain.ApplicationDbContext".
Don't forget to update .pubxml files:
<ObjectGroup Name="Vocabulary.Domain.ApplicationDbContext" Order="1" Enabled="True">
This article describes when publish dialog has or has no the tick "Execute Code First Migrations (runs on application start)"
This happened to me in VS2013. Neither cleaning the solution, nor restarting it worked. I tried to "re-enable" migrations and it worked. Even though I got an error message that migrations have already been enabled in project, the "Execute Code First Migrations" checkbox appeared again.
Since nothing mentioned above worked.
I downloaded the publish profile from azure and it worked flawlessly the first time
I had this problem and for me it had a different cause to any I've found documented elsewhere.
My application is spread over many projects in a solution. As I use interfaces and a separate View/Presentation model to wrap calls to the database, my front web project had no direct reference to the project containing the DbContext class. Note that this posed no problem to my running the site locally. I do this so that developers in the front end web project are not tempted to bypass the Presentation layer and go more directly to the database.
Adding this reference immediately fixed the problem and now I see the 'Execute Code First Migrations' checkbox in my Publish Profile dialog.
Just to add to the mix, don't call your Connection Class DbConn didn't seem to like that.
I have a build step that is part of my deployment configuration. My coworker told me it had worked once in a blue moon
I kept on getting this error consistently when I ran this build step:
Deleting dirPath (qa.comedy.net\aspnet_client\system_web\4_0_30319). [15:22:22]:
[VSMSDeploy] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.\We
\Microsoft.Web.Publishing.targets(3588, 5): Web deployment task failed.((3/28/2012 3:22:22 PM) An error occurred when the request was processed on the remote computer.)
Attempt to perform an unauthorized operation on file '4_0_30319'.
It seems that it is trying to delete the folder
aspnet_client\system_web\4_0_30319 , but has no permission to.
we run this build on a virtual machine.
Any suggestions on how to resolve this?
All help is greatly appreciated.
Thanks
I had this issue deploying as site with msdeploy and teamcity. I resolved it by deleteing these folders from my website aspnet_client\system_web\4_0_30319
Yes you can delete this folder and the next deploy will work, but with the next windows update that runs the asp.net registration tool as part of it's install will add this folder back to all asp.net sites on IIS (with the incorrect permissions) - so your deployment will fail again. You can avoid this by
Giving the deploy user elevated privileges (not a great solution for
obvious reasons)
Add the folder structure to your SC so it gets
deployed instead of the deployment trying to delete it (not ideal, but easiest)
Stop automatic windows updates (not sensible)
You might be able to do
something like this
http://blog.richardszalay.com/2012/12/18/demystifying-msdeploy-skip-rules/
to ignore the folder in deployment (I've not tried this)
As MemeDeveloper mentions in their answer, one way to fix this is to simply ignore that directory. Indeed, this is the easiest fix and doesn't require adding anything to your source control repository or build output. Just add the following to your msdeploy.exe command:
-skip:Directory="aspnet_client"
I wasn’t using TeamCity but I think I also had this issue. I was trying to deploy to Discount ASP.NET using VS2010 WebDeploy. After reading what doglin and Dan posted, I found I could workaround this problem by checking the “Leave extra files on destination (do not delete)” box. That may not be an option for everyone but it worked for me.
I faced the same problem during WebDeploy in TeamCity. I end up elevating privileges for WebDeploy account under which I do WebDeploy task. So the account have enough power to delete those folder (local admin role).
I have a few EJBs compiled with Weblogic's EJBC complient with Weblogic 9.2.1.
Our customer uses Weblogic 9.2.3.
During server start Weblogic gives the following message:
<BEA-010087> <The EJB deployment named: YYY.jar is being recompiled within the WebLogic Server. Please consult the server logs if there are any errors. It is also possible to run weblogic.appc as a stand-alone tool to generate the required classes. The generated source files will be placed in .....>
Consequently, server start takes 1.5 hours instead of 20 min. The next server start takes exactly the same time, meaning Weblogic does not cache the products of the recompilation. Needless to say, we cannot recompile all our EJBs to 9.2.3 just for this specific customer, so we need an on-site solution.
My questions are:
1. Is there any way of telling Weblogic to leave those EJB jars as they are and avoid the re-compilation during server start?
2. Can I tell Weblogic to cache the recompiled EJBs to avoid prolonged restarts?
Our current workaround was to write a script that does this recompilation manually before the EAR's creation and deployment (by simply running java weblogic.appc <jar-name>), but we would rather avoid this solution being used in production.
I FIXED this problem by spending a great deal of time researching
and decompiling some classes.I encountered this when migrating from weblogic8 to 10
by this time you might have understood the pain in dealing with oracle weblogic tech support.
unfortunately they did not have a server configuration setting to disable this
You need to do 2 things
Step 1.You if you open the EJB jar files you can see
ejb-jar.xml=3435671213
com.mycompany.myejbs.ejb.DummyEJBService=2691629828
weblogic-ejb-jar.xml=3309609440
WLS_RELEASE_BUILD_VERSION_24=10.0.0.0
you see these hascodes for each of your ejb names.Make these hadcodes zero.
pack the jar file and deploy it on server.
com.mycompany.myejbs.ejb.DummyEJBService=0
weblogic-ejb-jar.xml=0
This is just a Marker file that weblogic.appc keeps in each ejb jar to trigger the recompilation
during server boot up.i automated this process of making these hadcodes to zero.
This hashcodes remain the same for each ejb even if you execute appc for more than once
if you add a new EJB class or delete a class those entries are added to this marker file
Note 1:
how to get this file?
if you open domains/yourdomain/servers/yourServerName/cache/EJBCompilerCache/XXXXXXXXX
you will see this file for each ejb.weblogic makes the hashcodes to zero after it recompiles
Note 2:
When you generate EJB using appc.generate them to a exploded directory using -output C:\myejb
instead of C:\myejb.jar.This way you can play around with the marker file
Step2.
Also you need a PATCH from weblogic.When you install the patch you see some message like this
"PATH CRXXXXXX installed successfully.Eliminate EJB recomilation for appc".
i dont remember the patch number but you can request weblogic for that.
You need to use both steps to fix the problem.The patch fixes only part of the problem
Goodluck!!
cheers
raj
the Marker file in EJBs is WL_GENERATED
Just to update the solution we went with - eventually we opted to recompile the EJBs once at the Customer's site instead of messing with the EJBs' internal markers (we don't want Oracle saying they cannot support problems derived from this scenario).
We created two KSH scripts - the first iterates over all the EJB jars, copies them to a temp dir and then re-compiles them in parallel by running several instances of the 2nd script which does only one thing: java -Drecompiler=yes -cp $CLASSPATH weblogic.appc $1 (With error handling of course :))
This solution reduced compilation time from 70min to 15min. After this we re-create the EAR file and redeploy it with the new EJBs. We do this once per several UAT environment creations, so we save quite a lot of time here (55min X num of envs per drop X num of drops)