What does the /V1 parameter do for Schtasks.exe? - windows-task-scheduler

Microsoft's definition is not too helpful
/V1
A value that creates a task visible to Windows 2000, Windows Server 2003, and Windows XP platforms.
Windows XP and Windows Server 2003: This option is not available.
What would be a typical scenario this flag is used for?

Someone wrote that /V1 automatically populates the Start In field. It is annoying that there is no flag to set the Start In folder, but maybe /V1 takes care of that. Give it a try.

Related

ODBC connection to ACCDB in web.config

Want to connect to ACCDB file as an ODBC (rather than OleDb) data source in ASP.NET but struggling with the connection string. As I plan to deploy the web app from Visual Studio 2019 to Azure, I need something that can make the journey.
Here's what I tried from connectionstrings.com (I discovered not all of those strings are up to date or necessarily convenient for insertion to web.config):
Driver={Microsoft Access Driver (*.mdb, *.accdb)};Dbq=C:\mydatabase.accdb;Uid=Admin;Pwd=;
This returns keyword not supported: driver from IIS Express where I'm doing development.
Hum, that looks ok:
I would suggest this:
Driver={Microsoft Access Driver (*.mdb, *.accdb)};
dbq=C:\test\test44.accdb;driverid=25;fil=MS Access;
maxbuffersize=2048;maxscanrows=8;pagetimeout=5;safetransactions=0;
threads=3;uid=admin;usercommitsync=Yes
the above is what the connection builder in Visual Studio spits out.
and you have Dbq - carefull - caps I believe matters - so try dbq.
Next up:
HUGE HUGE elephant in the room.
are you using a x32 bit driver, or the x64 bit one? YOU MUST match your project bit size (code compile) settings to the driver (YOU MUST!!!).
So this:
you MUST set and force your project to run as x32 bits. (or perhaps install the x64 bit version of Access drivers. AND BE careful. If you are running the x64 bit versions of the drivers, and use Test connection with Visual Studio? It will always fail since VS runs as a x32 bit applcation. you MUST RUN the applcation to test the connection - NOT use test connection with VS connection builders (you might not be using them, but if you are, just trying to save you a day of work wasted).
so, create a x32 config project. And thus this now:
And I assume your sample connection using c: or "root" of the drive is a JUST a example, since most windows now don't allow a file to be used directly from c: root location.

Repair of application (msi) fails but normal installation is successfull

have web setup project created by VS 2010, when i setup this project all works fine, but when i check "repair" option i get error during installation.
MSI log file
Running process 'c:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe' with parameters ' -norestart -sn ""' silently...
Process Call Result Code: '0' Process Exit Code: '1'.
The error indicates that IIS is in 32 bit mode, while this application is a 64 bit application and thus not compatible.
Trying 32 bit version of 'aspnet_regiis.exe'...
Reading registry value Path from key 'HKLM\Software\Microsoft\ASP.NET\4.0.30319.0'...
RESULT Path =
Running process 'c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe' with parameters ' -norestart -sn ""' silently...
Process Call Result Code: '0' Process Exit Code: '1'.
The error indicates that IIS is in 64 bit mode, while this application is a 32 bit application and thus not compatible.
I couldnt uderstand why both 32-bit and 64-bit versions of aspnet_regiis not compatible to application?
When i check "setup" not "repair" option, path param is set to my application and setup works fine, so maybe i have to change something in my setup project?
IIS6 is set to 64-bit mode by the way ;)
Thanks
If you support 32 and 64-bit systems you need separate setups for both.
http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
so you'd run the appropriate aspnet exe for the system, that might solve some problems. You haven't said if your setup is x86 or x64, so it's hard to say what the exact issue might be. 32-bit processes cannot call 64-bit Dlls (and vice versa) so the 32-bit aspnet_regiis.exe can't call 64-bit assemblies in a 64-bit IIS, that's probably something to do with it.
That doesn't look like an MSI log file because it hasn't got all the info in there, like the MSI (s) (74:1C) [12:14:05:000]: type of intro, plust suff that would tell you if the call to the ProgramFiles folder is being redirected (look for WIN64DUALFOLDERS in the log).

How do I find out whether enabling gcServer config is taking effect?

I'm supporting a ASP.NET v2.0 app installed on a Windows 2003 SP3 Enterprise on a quad core 8G machine running on .NET 2.0 SP1.
before enabling the config, ran "tasklist /m mscorwks.dll"
Image Name PID Modules
w3wp.exe 7888 mscorwks.dll
add under section in web.config
ran IISRESET, rebooted server too
ran "tasklist /m mscorsvr.dll"
INFO: No tasks are running which match the specified criteria.
ran "tasklist /m mscorwks.dll"
Image Name PID Modules
w3wp.exe 6251 mscorwks.dll
It seems like gcServer is not taking effect. Are there any additional settings/ configurations necessary to get it working?
Update: Sorry, just saw that the link below, and thus maybe the whole information, applies to IIS 6.0. I don't know whether that is applicable to your environment.
I don't believe you can configure any GC setting on a per AppDomain basis, which is essentially what would happen when you only set it in a web.config file, thus on a per application basis.
You need to set this in the aspnet.config file. The Aspnet.config file is in the same directory as the Aspnet_isapi.dll file (check this for more information).
Edit: To figure out the GC in use, you can use WinDBG/SOS and the eeversion command:
0:010> !eeversion
2.0.50727.3082 retail
Workstation mode
SOS Version: 2.0.50727.3053 retail build
See this MSDN link, where Chapter 5 had the answer. Quote from Chapter 5:
Note: At the time of this writing, the .NET Framework 2.0 (code-named "Whidbey") includes both GCs inside Mscorwks.dll, and Mscorsvr.dll no longer exists.
I guess there is no way to check whether the server GC is working. EDIT: but see Christian's answer.
From code you can use GCSettings.IsServerGC.

Setting up IIS7.5 for local ASP.Net Development

Are there any particular settings one should optimally enable/disable/tweak when doing ASP.Net MVC development on local test machine Windows 7 using IIS 7.5 and moving in and out the debugger & recompiling refrequnetly (integration/troubleshooting stage now before TDD fantactics throw stones - although admittedly I could have more under test), I work with 64 bit edition but figure this probably applicable at both x86/x64?
I'll start with one:
Ping Period (seconds) - increase from 90 to 3000 (or something somewhat higher) so you can if unfortunately need to a good bit of time whilst debugging or disable ping on local test machine.
Credit: http://blogs.msdn.com/johan/archive/2007/09/12/my-web-application-times-out-when-debugging-in-iis7.aspx
However I see over stuff such as:
Disable Overlapped Recycle & Recycling settings etc.. that I wonder if could increase performance or make debugging less friction
Question prompted by the annoyance that I've ran across a few recent debugging issues (not apparent in production) including a random, and tempormental error "An assembly with the same simple name blah-blah-lah-assembly-definiton has already been imported . Try removing one of the references or sign them to enable side-by-side." (iisreset resovles) and generally slow debugging attaching. The points and answers to this question need not help with the above (I believe it may be related to spark view engine as that where the stacktrace ends) but figure it worth mentioning incase someone has a direct suggestion *
quick tip: if you're experiencing slow response times (~1-1.5 sec) from browsers other than internet explorer (eg: firefox, chrome, safari) while running your mvc/ other web app on your local machine using win7/vista, it is due to dns resolution with ipv6.
firefox solution: disable ipv6 in about:config (boolean cfg 'network.dns.disableIPv6')
machine wide soft solution: uncomment the good old localhost address in the hosts file (%WINDIR%\System32\drivers\etc\hosts):
# localhost name resolution is handled within DNS itself.
127.0.0.1 localhost
# ::1 localhost
machine wide hard solution: disable ipv6 completely
credit goes to this blogpost: http://weblogs.asp.net/dwahlin/archive/2007/06/17/fixing-firefox-slowness-with-localhost-on-vista.aspx
Embarcadero guys just published a fresh article on similar topic for Delphi Prism (aka Delphi for .NET), so why not take a look on their suggestions?
http://edn.embarcadero.com/article/40108
From the experience i have working with asp.net mvc, i can tell that there are no special settings for IIS 7 or IIS 7.5 for working on asp.net mvc projects. It works fine in the default form, you just need to create a new website and point it to the folder that has the files for you application.
For debugger if you ask, you can simply put a breakpoint in the code and hit that breakpoint when you run the application from visual studio. But by default the application will use the development web server that fires up when you run a web application from visual studio. If you want to the application to run using the IIS installed on your system you will have to change the project settings. See here for a screen shot of how to do so
http://blogs.bootcampedu.com/blog/post/Debugging-aspnet-mvc-application-using-IIS.aspx
Additionally you can also use System.Diagnostics.Debugger.Break(); for putting a break point in the code.
If you only want to debug your application, I recommend to use the built-in development server of Visual Studio.
If you debugged the most of it or want to do that on IIS, I recommend you the Ctrl+Alt+P shortcut, which enables you to attach a debugger. Select w3wp.exe and you can debug with IIS.

Visual Studio Development Server using wrong port

Related to a previous issue that I thought was resolved and actually isn't...
My Visual Studio 2008 installation may be a bit messed up, I think.
When my ASP.NET project is set up to use VS Dev Server with a fixed port, I get the "Port in use" error described in the linked question.
When my project is set up to use a random (auto-assigned) port number, it works, but it launches the browser using a port number 3 less than the actual Dev Server port number (e.g. if the port number is 1903, the browser launches to http://localhost:1900/)
If I make changes to the project settings, they do not "take" until I save and restart Visual Studio.
Any ideas how to track this one down?
Thanks!
I had a similar problem which hit my 2 main machines at the same time. On investigating I found it to be related to the Eset personal security (guessing a recent update messed something up). To solve it I excluded VS2008 from the active browser filtering - this is in:
setup -> advanced firewall setup -> antivirus & anti spyware -> web access protection -> HTTP -> webbrowsers
Deselecting vsdev in here fixed the problem - interestingly enough disabling the firewall and antivirus / antispyware did not solve the issue, so it is worth looking for a similar setting if you are running different security software
First try to kill all "WebDev.WebServer.exe" processes.
In Solution Explorer, click the name of the application.
In the Properties pane, click the down-arrow beside Use dynamic ports and select False from the dropdown list.This will enable editing of the Port number property.
In the Properties pane, click the text box beside Port number and type in a port number.
Click outside of the Properties pane. This saves the property settings.
Hope this helps
I do absolutely agree with Macros' answer. Just want to share solution for Eset Nod32 v5
In ESET NOD32 v5 to allow Visual Studio to run Development or IIS Express server you must uncheck Visual Studio in Nod32 Advanced Setup => Web and Email => Protocol filtering => Web and email clients
Weird!
The port number is stored in the .sln file. So, I'd blow that away the solution file first, re-create it and see what happens. If that doesn't help, I'd then move onto the web.config file and blow that away and start again too.
I also encountered the same error message:
Unable to launch Visual Studio development server because port [xxxx] is in use.
However, I do not have ESET installed. Instead, I had recently installed GlassFish server on my machine and that was causing the problem. Therefore, in Windows Task Manager, I killed the process it runs under which is java.exe and it fixed the problem.
This also applies to Visual Studio 2010.
And there is more to it.
Symptoms:
A Web (Services) project is configured to run at a specific port, e.g. 10080.
After a while Visual Studio compains “Unable to launch the Visual Studio Development Server because port ’10080′ is in use”
The reason is still unclear. It might have something to do with the webdev server crashing.
Restarting the pc doesn't solve the problem.
Netstat doen’t show an entry for the port 10080
Manually startin WebDev.WebServer40.exe at port 10080 works fine.
Since I'd like to start from within Visual Studio, I moved to port 10081, then to 10082, and today to 10083. I’m running out of ports.
Solutions that did not work:
Restart Visual Studio
Tweaking Trendmicro security settings (couldn't access them)
Disabling Forticlient antivirus/firewall
Workaround that DOES work:
Configuring my project to manually start the server
Right click the project, choose properties
Click the tab "Web"
Pick for start action "Start external program" and point it to Webdev.Webserver40.EXE
(for me: C:\Program Files (x86)\Common Files\Microsoft Shared\DevServer\10.0\WebDev.WebServer40.EXE)
Command line arguments: /port:10080 /path:C:\Solution\Project
Working directory: C:\Solution\Project
Under servers check "Use Custom Web Server"
Do not check any debugger checkbox
Side effect: my project thinks break points are not getting hit. ("no symbols loaded"). Turns out they work like they should.
I hope anybody ever finds a definitive solution, but up until then this workaround does the trick for me.
To solve your problem, just restart your PC. I've had the same problem, I did the same thing.

Resources