[ I submitted this question 2 months ago and didn't have any replies ... and obviously the problem is still live and we are about to release a new version of our app, so now am writing some documentation to get the users to delete any entries in the virtual store - something I didn't want to do .... so now really hoping someone out there can help us ?! ]
I appreciate that there is a lot of info regarding this topic, but I am still having an annoying issue and not sure where to go with it ... hence coming here !!
We have an app (VB.NET) that now installs REPORT files into a folder under ProgramData. Now our app dll is run from a third party app ( that we obviously have no control over ) and this third party app allows people to run the reports; but when a report is run, it then updates the report, so that it's "last run date" is stored. This is what is causing us the fun we are having.
With UAC on, the report files are been copied to the equivalent location within the Virtual Store. This of course is ok while they are using the current version of our app, but when we release a new version ( with modified reports ) these new versions are getting installed correctly into ProgramData, but when the user runs the app - they are seeing the outdated reports from Virtual Store.
We are very close to writing some installation documentation, telling folk to delete any reports from Virtual Store, before installing our new version - but this is a real cop out !!
The third party app also installs its own reports ( into a different location under ProgramData ) and they are able to update their reports without Virtual Store kicking in - so we know it's possible !
I have just added a manifest to our dll :
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
hoping that would be the cure, but alas no !
So, I'm open to any suggestions that you folk may have ?!?
Cheers,
Chris.
VirtualStore is used when the user doesn't have permissions to write into the requested program folder. So the simpliest solution is to give your users permission. Actually, I like to use a user group so there is some security left.
System Tools > Local Users and Groups > Groups, "New group" and create say "XYZCompanyUsers".
Windows Explorer > Program Files (x86) > XYZCompany, "Properties" "Security". Now add the new group "XYZCompanyUsers" and give them full permissions.
The application needs to have the assembly manifest.
Putting asInvoker in the assembly manifest of a .dll will not help you.
Now our app dll is run from a third party app ( that we obviously have no control over )
You need to tell the 3rd party app to write a correct Windows application. And correctly written Windows applications have an assembly manifest. If their .exe does not have a manifest, then it is not a correctly written Windows application. (A manifest is part of the Windows programming ground rules).
if they don't have a manifest: you can create your own and place it in their executable (e.g. using ResourceHacker, or MT which can be found in the Windows 10 SDK)
or you can edit their existing assembly manifest (again using Resource Hacker) to include the asInvoker attribute
or you can place an external (CotosoApp.exe.manifest) manifest
Related
I am trying to find a way to run MVC6 application on IIS but without actually doing the publish. I am not sure if that is possible, and if not will it be possible in the future?
I would like to have similar behavior like on previous versions where I could easily debug my code and make changes while the application is running under IIS.
From your original question (emphasis added):
I am trying to find a way to run MVC6 application on IIS but without actually doing the publish.
From your comment to tugberk (emphasis added):
Right now every time when I make a change I need to call that dnu publish command in order to see my changes on IIS. I would like to see them only by doing rebuild.
Answer and reasons
You'll need to publish. There are at least two reasons:
IIS needs build output and
IIS needs a web.config file.
IIS might need a few other things too, about which I'm not aware. So, you'll need to publish. This isn't a big deal: after the onetime setup, publish doesn't take much longer than rebuild does.
Why do you need to publish?
In Visual Studio 2015, if you build an ASP.NET 5 web app, there will be no build output under your solution's directory, and IIS needs build output. By default Roslyn only runs code analysis without emitting build output.
You can change that default, so that Roslyn does emit build output, but that won't produce the web.config file that IIS needs. By going to View > Project Properties > Build and checking "Produce outputs on build", Roslyn will emit output to the artifacts directory. E.g:
artifacts/bin/MyWebApp/Debug/MyWebApp.1.0.0.nupkg
artifacts/bin/MyWebApp/Debug/MyWebApp.1.0.0.symbols.nupkg
artifacts/bin/MyWebApp/Debug/app/project.json
artifacts/bin/MyWebApp/Debug/dnx451/MyWebApp.dll
artifacts/bin/MyWebApp/Debug/dnx451/MyWebApp.pdb
artifacts/bin/MyWebApp/Debug/dnx451/MyWebApp.xml
artifacts/bin/MyWebApp/Debug/dnxcore50/MyWebApp.dll
artifacts/bin/MyWebApp/Debug/dnxcore50/MyWebApp.pdb
artifacts/bin/MyWebApp/Debug/dnxcore50/MyWebApp.xml
If you point IIS at the artifacts directory, you'll now have the problem of having neither a wwwroot nor a web.config.
So, you need to publish (or work out some other convoluted solution) for IIS to work with ASP.NET 5. There is a onetime setup if you want to publish from Visual Studio to a local IIS website. After the onetime setup, you can make changes to your code and publish in two clicks. Here's the onetime setup:
Right click the project.
Choose Publish.
Select File System and add a profile name (e.g. inetpub).
Change the target location to C:\inetpub\MyWebApp
In Settings, select appropriate settings. E.g.
Configuration: Debug
Target DNX Version: dnx-clr-win-x64.1.0.0-beta4
Click Publish.
Once publish completes, point IIS at C:\inetpub\MyWebApp\wwwroot and you will be able to browse to the web site. Further to the point, you can now change your code, publish in two clicks, and refresh your IIS site to see the changes.
Some gotchas
If you do choose to publish to inetpub, be sure to run Visual Studio as administrator, lest you receive an insufficient permissions error.
If you accept the default publish location (instead of using inetpub as shown above) watch out for path too long errors (i.e. > 260 characters.)
Final thoughts
Why not use Visual Studio and Debug > Start without debugging during development. With Roslyn and Visual Studio 2015, you can make changes to the code and see those changes by refreshing the web browser. No rebuild is necessary. It's a much nicer workflow.
It's possible. Under the root of your project (project.json directory), run the following command:
dnu publish --runtime active --out bin/artifacts
Once the publish is done, you have some stuff under bin/artifacts folder. Point IIS application pool to bin/artifacts/wwwroot folder we have just created and it should work. Keep in mind that you at least need .NET 4.5.1.
I'm assuming this is a development on IIS question. It's doable but it requires some work. The reason IIS doesn't work out of the box without a publish is because there is no user profile setup on app pools by default. The simplest thing you can do is to enable the user profile on the app pool, that will allow IIS to find the runtime in the user profile folder. On top of that, you require a web.config to specify which version of the runtime to use (dnu publish generates this for you so if you want, you can do a publish and copy the runtime folder). After doing that, pointing IIS to the wwwroot should just work (assuming you setup the right web.config with the right runtime and the right bitness).
You also need the correct AspNet.Loader.dll in the bin folder. If you use visual studio, it'll copy it in the right place.
Based on davidfowl answer i ran ASP.NET MVC6 on IIS without publishing application. But i still can't start debug it by F5(only by attaching to w3wp.exe).
Anyway i hope it would be helpful:
In the root of the project add "packages" directory(or name it whatever you like).
In global.json file add "packages": "packages". e.g.:
{
"projects": [
"src",
"test",
"wrap"
],
"sdk": {
"version": "1.0.0-beta4"
},
"packages": "packages" // <--
}
Packages will be now stored in this directory.
Create a "runtimes" directory in the root of your project.
Copy a runtimes from %userprofile%/.dnx/runtimes to /path/to/your/project/runtimes
Create a web.config in wwwroot of you project. e.g.:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="bootstrapper-version" value="1.0.0-beta4" />
<add key="dnx-version" value="1.0.0-beta4" />
<add key="dnx-clr" value="clr" />
<add key="dnx-app-base" value=".." />
<add key="runtime-path" value="../../../runtimes" />
</appSettings>
</configuration>
Create web application in IIS and point it to your project wwwroot.
My project directory structure:
Projects/
vNext/
packages/
runtimes/
dnx-clr-win-x64.1.0.0-beta4/
dnx-clr-win-x86.1.0.0-beta4/
...
src/
vNext/
wwwroot/ <-- IIS web application points here
web.config
...
project.json
...
global.json
vNext.sln
...
After this you will be able to attach to w3wp.exe and debug your application running under IIS.
I'm facing a really strange problem.
I have an application built in C++ Builder 2010. This application reads and writes a bit to the registry. Since it's a 32-bit application these keys end up in the wow6432Node. Every now and then it has appeared as though it has trouble reading the values from the registry. But only when build on the build server (using TeamCity) and never on the dev machines. Often a new commit and a rebuild would make the issue go away so it was hard to diagnose.
After some testing I noticed that I was able to reproduce it on the dev machine to. But only when building from the command line by calling msbuild manually. If the exact same project is built within the IDE there are no issues. But the exe produced when building from the command line, for some reason, can't read values from the registry.
There are no errors or warnings during builds. No files it can't find due to invalid paths or anything like that. Since msbuild is, as far as I can tell, used by the IDE when building to this has me scratching my head. I have tried to manually use different versions of msbuild etc, but nothing works.
So basically, on the same machine, my produced exe behaves differently depending on if I manually started the build from the command line or if the IDE started the build.
What on earth could this be?
After spending a lot of time trying to force the application to use specific registry views etc I was encouraged to look into the UAC manifest settings. I found that the application did in fact have a manifest file, named correctly and in the correct spot. It was also included in the .cbproj file and compiled by the resource compiler.
But, something got me thinking that perhaps it's not being used correctly. After some digging it seems like if runtime themes is enabled for the project that will create a "default" application manifest that will be used.
Disabling runtime themes will allow the compiler to actually use your custom application maniftest file (not exactly well documented, but I have found that to be the case with a lot of Embarcaderos things). By doing this I was able to set the required execution level for the application and things started to work just fine.
You can still manually enable the support for runtime themes in the maniftest file you create. You forms might look a bit strange in the ide since that will think that runtime themes are disabled.
To manually add runtime theme support you add the dependency to your custom application maniftest.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
...
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="*"
/>
</dependentAssembly>
</dependency>
...
</assembly>
Save it as Foo.exe.manifest, where Foo.exe is your application name.
You then create a .rc file for your application. For instance FooManifest.rc
#define MANIFEST_RESOURCE_ID 1
#define RT_MANIFEST 24
MANIFEST_RESOURCE_ID RT_MANIFEST "Foo.exe.manifest"
Now you will be able to build your application using your own custom application manifest and still maintain support for runtime themes.
Reading up on background agents in Windows Phone. All guides say I should start with creating a new project specifically for the agent. Is that a requirement? Cite place.
The bigger question is - how does the framework find the class that implements the scheduled task? AFAIK, starting a background task involves calling ScheduledActionService.Add() passing a ScheduledAction-derived object as a parameter. Nowhere in here can I see any pointer to the identity of task's implementation. Neither are tasks registered in the manifest.
Yes, the background task needs to be located in separate project. In theory the background task could be in the original project, but then it will easily hit the memory cap, because the whole project needs to be loaded in order to run just the background task code.
It also needs to be added into your main app project using "Add reference".
The project with background task also need to have class, that is a child of ScheduledTaskAgent class.
Then (in case of WP8 app) when your app is built using Visual Studio and if the Visual Studio finds such referenced project with ScheduledTaskAgent, new entry is injected into the WMAppManifest.xml to tell the app launcher that this app has background task available and in case user actually register this task for running, WP OS should start the assembly located in app manifest. This is how it looks in the manifest file:
<Tasks>
<DefaultTask Name="_default" NavigationPage="MainPage.xaml" ActivationPolicy="Resume" />
<ExtendedTask Name="BackgroundTask">
<BackgroundServiceAgent Specifier="ScheduledTaskAgent" Name="EreaderBackgroundAgent" Source="EreaderBackgroundAgent" Type="EreaderBackgroundAgent.ScheduledAgent" />
</ExtendedTask>
</Tasks>
The DefaultTask entry just describes the default app entry point, the ExtendedTask is the entry for background task.
Note also that when developing apps for Windows Phone 7.5, this entry had to be added manually into the manifest and it was a common problem that devs published app without this entry in manifest.
Also another interesting discovery, if you reference in your main project -> libraryA, that is referencing another libraryB, and only the libraryB implements the ScheduledTaskAgent, then Visual Studio won't add the entry into manifest, because it cannot check indirectly referenced projects - if the libraryA has no ScheduledTaskAgent implementation, the library is not considered as background task library. But, you can again add the entry to libraryA into manifest manually and it will work just fine.
Neither are tasks registered in the manifest.
They are. See the "BackgroundServiceAgent" element in your manifest file: http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff769509(v=vs.105).aspx
In the end, I don't know if creating a separate project is a requirement. By manually adding the line in the manifest and pointing to a class in the main project, I don't see what could technically prevent the background agent from working. I haven't tried though. Still, putting the background agent in a separate assembly can be convenient: the memory limit for agents is ridiculously low, so not having to load the main project and its dependencies can probably save a few hundreds KB of memory
I am trying to publish my application using installShield utility. Every thing works fine but it gives warning that it asks for two files:
libc.dll
Flash32_11_7_700_224.ocx
Those two files are prerequisite according to the package but I could not find them.
I tried to search in the web for those two files with no luck.
Can any one help in this?
Explanation of Error
This error can be encountered in Flexera's InstallShield. The specific error is:
ISEXP : warning -6248: Could not find dependent file <dependent file>,
or one of its dependencies of component <component>
The official troubleshooting information from helpnet.installshield.com did not help me, but it says to:
Use the "Build Tables & Refresh Files" option to build the release
if the release location is in <ISProjectDataFolder>
or <ISProjectFolder>. For more information, see "How the Run time
Locates Assemblies", available in the .NET Framework SDK help or on MSDN.
Workaround
If the application works fine, and you just want to get rid of the warnings, you can follow this Stack Overflow Q&A.
(InstallShield, Installation Designer, Left Panel) Specify Application Data > Files
(Destination computer's files panel) Right click primary output > Dependencies from scan at build... > Uncheck dependencies you do not want
The above picture from the Stack Overflow answerer #Tom Wilson shows what you should see. Note that primary output was the central .exe of my project. When I used this technique on my primary output, the other components in my project were also fixed.
Resolution
If this problem is crashing your application, and not just an annoying warning...
In the case of libc.dll, I would direct you to add Redistributables to your project.
(InstallShield, Installation Designer, Left Panel) Specify Application Data > Redistributables
For instance, I use Microsoft .NET Framework 4.7.1 Full.
I believe this solution will work for libc.dll, but cannot verify. I base this on reading support.microsoft.com, which I think implies libc.dll is contained in C Run-Time (CRT), which I would also believe is part of the .NET Framework.
In the case of flash32_11_7_700_224.ocx, I would direct you to System Software Requirements. This ocx is installed with many Adobe products. You may want to prompt the user that they need to install this, at the time software installation.
(InstallShield, Installation Designer, Left Panel) Define Setup Requirements and Actions > Requirements
(Central Panel) System Software Requirements > Right click > Create New Launch Condition (System Search Wizard)
Follow the wizard there to block installment if it does not exist, or use one of the premade requirements if that helps your case. Tip: remember to supply a link to Adobe in your prompt, so your end-user can quickly download it!
We have a ASP.NET MVC with 4-5 different build configurations. Whenever we change the build configuration, we need to delete the obj folder for the web project, since we get the 'allowDefinition='MachineToApplication' error. A pain, but we managed by deleting the folder in pre/post build events.
Now I need to configure our CI to build deployment packages. This means that I cannot delete the obj folder. Every time I compile e.g. with the following msbuild parameters
/p:CreatePackageOnPublish=true /p:DeployOnBuild=true
I recieve the error:
web.config(123): error ASPCONFIG: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
As far as I understand, the problem is that there's multiple .config files in the project - In our case, there's not. I could really use some help to find an explanation and find a permanent (no- hack) fix.
Edit:
This question is marked as a duplicate, but the corresponding answers and cause(s) in the 2 threads, are clearly different from each other. Not sure what is intended with this tag - I've read that particular post before posting this question, as it didn't answer my question. There's multiple causes for this error message. It is 'similar', but definitely not a duplicate!
There is a similar question here on SO with some good solutions for this issue.
The problem is that building a deployment package creates a copy of the web.config in a subfolder of /obj. That will normally be be cleared out if you do a rebuild or a clean. However, if you build a deployment package in one configuration (e.g. Debug) and then switch to another confguration (e.g. Release) the obj/Debug folder is not cleared out and the web.config file there causes problems.
The quick solution is to clean all configurations and then do a (re)build. Alternatively you could delete the /obj folder in your project.
To permanently resolve the issue you can either move the intermediate output (/obj) out of your project folder or modify the project to force a clean of all configurations on rebuild.
I too was deleting the obj folder until I had a conflict with a build script which required it. Catch-22, I used the accepted answer on the following SO link to move the location of the Obj folder to C:\Temp\BUILD. You have to do it per csproj file, but it is a great solution.
Here is the link: VisualStudio: How to save the obj folder somewhere else
Note that I am using a variable for the project name.
R:\Temp\Build\Debug\$(MSBuildProjectName)
I have the above line in both debug and release sections for all my projects, including class projects. My build path is a ram drive for speed. See this SO for more info: How to access macro variables within csproj file?
I just answered a similar question here. To recap, I ran into this problem in one of our MVC projects, and it was due to having the MvcBuildViews property in the project file set to true. Setting the property to false fixed the problem.
<MvcBuildViews>false</MvcBuildViews>
I also found this answer which outlines an alternative that does not require turning off view building.
I don't know that there is an "official" fix as it just seemed to start on multiple projects of mine for no reason that I can find in Visual Studio Premium 2012 (never happened in previous versions of VS).
As a work around to automate the deletion of the obj directory as others have said, similar to an answer by user Casual in this post VisualStudio: How to save the obj folder somewhere else, where unfortunately just moving the location of the obj folder didn't always seem to work.
Instead I added a few commands under Build Events in the Pre-build event command line:
rd "$(ProjectDir)obj" /S /Q
md "$(ProjectDir)obj"
md "$(ProjectDir)obj\Debug"
md "$(ProjectDir)obj\Release"
You can change/add/remove subfolders to match your custom build configurations using the line where buildConfigName matches the name of the build configuration you are using:
md "$(ProjectDir)obj\buildConfigName"
Hope this helps!
That error indicates that you are trying to something specific to an application at an IIS tree level that isn't defined as an application. For example if you try to do app-level functions in a web.config in a virtual directory, you will get that error. You need to find the path you are deploying to and make sure that it is defined in IIS as an application vs a folder or vdir.
Cleaning the solution (Right click Solution in VS, clean), worked for me.
I had the same error but with a deployed page.. Then realized my webserver's clock was set back to 2010 for some reason. set it to the correct date fix my problem
Clean your project
Remove the /obj folder (probably using publish and deploy? - there is a bug in it)
Althoug the problem is explained and solved in one way in the accepted answer, I wanted to show a solution which can be better for other cases. This solution has been included in some version of VS, but I can only say that I had the problem in VS 2013 Update 5. (See the "Beware" below, it could be fixed in this version, but not working only in my particular case).
I borrowed the soltuion from Error: allowDefinition='MachineToApplication' beyond application level on Visual Studio Connect.
The solution consist in including these lines to the web application project (.csproj file) which handle the deletion of the offedning intermediate files (which wans't a solution for the accepted answer, as he needed those intermediate files):
<!--Deal with http://connect.microsoft.com/VisualStudio/feedback/details/779737/error-allowdefinition-machinetoapplication-beyond-application-level,
we will need to clean up our temp folder before MVC project starts the pre-compile-->
<PropertyGroup>
<_EnableCleanOnBuildForMvcViews Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='' ">true</_EnableCleanOnBuildForMvcViews>
</PropertyGroup>
<Target Name="CleanupForBuildMvcViews" Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='true' and '$(MVCBuildViews)'=='true' " BeforeTargets="MvcBuildViews">
<ItemGroup>
<_PublishTempFolderNamesToCleanup Include="Database;TransformWebConfig;CSAutoParameterize;InsertAdditionalCS;ProfileTransformWebConfig;Package;AspnetCompileMerge" />
</ItemGroup>
<!--Force msbuild to expand all the wildcard characters so to get real file paths-->
<CreateItem Include="#(_PublishTempFolderNamesToCleanup->'$(BaseIntermediateOutputPath)**\%(identity)\**\*')">
<Output TaskParameter="Include" ItemName="_EvaluatedPublishTempFolderNamesToCleanup" />
</CreateItem>
<Delete Files="#(_EvaluatedPublishTempFolderNamesToCleanup)" />
</Target>
Beware: for some reason, probably because I included it myself in the project, my build target for building the views was named "BuildViews", instead of "MvcBuildViews", so I had to modify the BeforeTargets attribute accordingly.
This is not necessarily the exact same issue, and to be honest, probably down to pure lack of knowledge on my part, however I had this same error when:
I set up a standard asp.net new project actually just used for HTML5 stuff so nothing other than the usual project structure
I then (not thinking perhaps!) added a new WCF REST project (which actually was just another base asp.net project using very good examples from http://www.codeproject.com/Articles/128478/Consuming-WCF-REST-Services-Using-jQuery-AJAX-Call?fid=1597004&df=90&mpp=25&noise=3&prof=False&sort=Position&view=Quick&fr=26#xx0xx and http://geekswithblogs.net/michelotti/archive/2010/08/21/restful-wcf-services-with-no-svc-file-and-no-config.aspx
The problem was I added the WCF REST project (#2) as a SUB-DIRECTORY of the main project (#1) and then tried to build! even if I cleaned the project of course.. I also made both projects use IISexpress because I thought there was an issue using the same port or something.
Of course the build process saw the web.config from #1 and then a sub-dir with another web.config #2..
I realise this probably should be a very basic understood gotcha and it has caught me out a while ago, however sometimes it's the simplest of mistakes that are a real pain!
Might help others... who perhaps haven't had their morning coffee..
tip 1: clean & then rebuild.
tip 2: just close VS and open again.
tip 3: the downloaded project may be inside another sub folder... open the folder which has you .net files.
c:/demo1/demo/ (all files)
You should have to open demo from vs... not demo1.
I have a somewhat a similar problem, i had the main config as Copy Always so it copied the config to the bin directory. When i republished the main project, i got the MachineToApplication error. So my solution was to just change the config to Do Not Copy and remove the extra configuration in the bin folder.